home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1573.txt < prev    next >
Text File  |  1994-08-01  |  123KB  |  3,084 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      K. McCloghrie
  8. Request for Comments: 1573                            Hughes LAN Systems
  9. Obsoletes: 1229                                            F. Kastenholz
  10. Category: Standards Track                                   FTP Software
  11.                                                             January 1994
  12.  
  13.  
  14.               Evolution of the Interfaces Group of MIB-II
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Table of Contents
  25.  
  26.    1. Introduction .............................................    2
  27.    2. The SNMPv2 Network Management Framework ..................    2
  28.    2.1 Object Definitions ......................................    3
  29.    3 Experience with the Interfaces Group ......................    3
  30.    3.1 Areas of Clarification/Revision .........................    3
  31.    3.1.1 Interface Numbering ...................................    4
  32.    3.1.2 Interface Sub-Layers ..................................    4
  33.    3.1.3 Virtual Circuits ......................................    5
  34.    3.1.4 Bit, Character, and Fixed-Length Interfaces ...........    5
  35.    3.1.5 Counter Size ..........................................    5
  36.    3.1.6 Interface Speed .......................................    6
  37.    3.1.7 Multicast/Broadcast Counters ..........................    6
  38.    3.1.8 Addition of New ifType values .........................    6
  39.    3.1.9 ifSpecific ............................................    6
  40.    3.2 Clarifications/Revisions ................................    7
  41.    3.2.1 Interface Numbering ...................................    7
  42.    3.2.2 Interface Sub-Layers ..................................    8
  43.    3.2.3 Guidance on Defining Sub-layers .......................   11
  44.    3.2.4 Virtual Circuits ......................................   12
  45.    3.2.5 Bit, Character, and Fixed-Length Interfaces ...........   12
  46.    3.2.6 Counter Size ..........................................   14
  47.    3.2.7 Interface Speed .......................................   16
  48.    3.2.8 Multicast/Broadcast Counters ..........................   16
  49.    3.2.9 Trap Enable ...........................................   17
  50.    3.2.10 Addition of New ifType values ........................   17
  51.    3.2.11 InterfaceIndex Textual Convention ....................   17
  52.    3.2.12 IfAdminStatus and IfOperStatus .......................   18
  53.    3.2.13 Traps ................................................   19
  54.    3.2.14 ifSpecific ...........................................   20
  55.  
  56.  
  57.  
  58. McCloghrie & Kastenholz                                         [Page 1]
  59.  
  60. RFC 1573               Interfaces Group Evolution           January 1994
  61.  
  62.  
  63.    3.3 Media-Specific MIB Applicability ........................   20
  64.    4. Overview .................................................   21
  65.    5. IANAifType Definition ....................................   22
  66.    6. Interfaces Group Definitions .............................   24
  67.    7. Acknowledgements .........................................   53
  68.    8. References ...............................................   53
  69.    9. Security Considerations ..................................   55
  70.    10. Authors' Addresses.......................................   55
  71.  
  72. 1.  Introduction
  73.  
  74.    This memo defines a portion of the Management Information Base (MIB)
  75.    for use with network management protocols in the Internet community.
  76.    In particular, it describes managed objects used for managing Network
  77.    Interfaces.
  78.  
  79.    This memo discusses the 'interfaces' group of MIB-II, especially the
  80.    experience gained from the definition of numerous media-specific MIB
  81.    modules for use in conjunction with the 'interfaces' group for
  82.    managing various sub-layers beneath the internetwork-layer.  It
  83.    proposes clarifications to, and extensions of, the architectural
  84.    issues within the current model used for the 'interfaces' group.
  85.  
  86.    This memo also includes a MIB module.  As well as including new MIB
  87.    definitions to support the architectural extensions, this MIB module
  88.    also re-specifies the 'interfaces' group of MIB-II in a manner which
  89.    is both compliant to the SNMPv2 SMI and semantically-identical to the
  90.    existing SNMPv1-based definitions.
  91.  
  92. 2.  The SNMPv2 Network Management Framework
  93.  
  94.    The SNMPv2 Network Management Framework consists of four major
  95.    components.  They are:
  96.  
  97.       o    RFC 1442 which defines the SMI, the mechanisms used for
  98.            describing and naming objects for the purpose of management.
  99.  
  100.       o    STD 17, RFC 1213 defines MIB-II, the core set of managed
  101.            objects for the Internet suite of protocols.
  102.  
  103.       o    RFC 1445 which defines the administrative and other
  104.            architectural aspects of the framework.
  105.  
  106.       o    RFC 1448 which defines the protocol used for network access
  107.            to managed objects.
  108.  
  109.    The Framework permits new objects to be defined for the purpose of
  110.    experimentation and evaluation.
  111.  
  112.  
  113.  
  114. McCloghrie & Kastenholz                                         [Page 2]
  115.  
  116. RFC 1573               Interfaces Group Evolution           January 1994
  117.  
  118.  
  119. 2.1.  Object Definitions
  120.  
  121.    Managed objects are accessed via a virtual information store, termed
  122.    the Management Information Base or MIB.  Objects in the MIB are
  123.    defined using the subset of Abstract Syntax Notation One (ASN.1)
  124.    defined in the SMI.  In particular, each object object type is named
  125.    by an OBJECT IDENTIFIER, an administratively assigned name.  The
  126.    object type together with an object instance serves to uniquely
  127.    identify a specific instantiation of the object.  For human
  128.    convenience, we often use a textual string, termed the descriptor, to
  129.    refer to the object type.
  130.  
  131. 3.  Experience with the Interfaces Group
  132.  
  133.    One of the strengths of internetwork-layer protocols such as IP [6]
  134.    is that they are designed to run over any network interface.  In
  135.    achieving this, IP considers any and all protocols it runs over as a
  136.    single "network interface" layer.  A similar view is taken by other
  137.    internetwork-layer protocols.  This concept is represented in MIB-II
  138.    by the 'interfaces' group which defines a generic set of managed
  139.    objects such that any network interface can be managed in an
  140.    interface-independent manner through these managed objects.  The
  141.    'interfaces' group provides the means for additional managed objects
  142.    specific to particular types of network interface (e.g., a specific
  143.    medium such as Ethernet) to be defined as extensions to the
  144.    'interfaces' group for media-specific management.  Since the
  145.    standardization of MIB-II, many such media-specific MIB modules have
  146.    been defined.
  147.  
  148.    Experience in defining these media-specific MIB modules has shown
  149.    that the model defined by MIB-II is too simplistic and/or static for
  150.    some types of media-specific management.  As a result, some of these
  151.    media-specific MIB modules have assumed an evolution or loosening of
  152.    the model.  This memo is a proposal to document and standardize the
  153.    evolution of the model and to fill in the gaps caused by that
  154.    evolution.
  155.  
  156.    A previous effort to extend the interfaces group resulted in the
  157.    publication of RFC 1229 [7].  As part of defining the evolution of
  158.    the interfaces group, this memo applies that evolution to, and
  159.    thereby incorporates, the RFC 1229 extensions.
  160.  
  161. 3.1.  Areas of Clarification/Revision
  162.  
  163.    There are several areas for which experience indicates that
  164.    clarification, revision, or extension of the model would be helpful.
  165.    The next sections discuss these.
  166.  
  167.  
  168.  
  169.  
  170. McCloghrie & Kastenholz                                         [Page 3]
  171.  
  172. RFC 1573               Interfaces Group Evolution           January 1994
  173.  
  174.  
  175. 3.1.1.  Interface Numbering
  176.  
  177.    MIB-II defines an object, ifNumber, whose value represents:
  178.  
  179.      "The number of network interfaces (regardless of their
  180.      current state) present on this system."
  181.  
  182.    Each interface is identified by a unique value of the ifIndex object,
  183.    and the description of ifIndex constrains its value as follows:
  184.  
  185.      "Its value ranges between 1 and the value of ifNumber.  The
  186.      value for each interface must remain constant at least from
  187.      one re-initialization of the entity's network management
  188.      system to the next re-initialization."
  189.  
  190.    This constancy requirement on the value of ifIndex for a particular
  191.    interface is vital for efficient management.  However, an increasing
  192.    number of devices allow for the dynamic addition/removal of network
  193.    interfaces.  One example of this is a dynamic ability to configure
  194.    the use of SLIP/PPP over a character-oriented port.  For such dynamic
  195.    additions/removals, the combination of the constancy requirement and
  196.    the restriction that the value of ifIndex is less than ifNumber is
  197.    problematic.
  198.  
  199. 3.1.2.  Interface Sub-Layers
  200.  
  201.    Experience in defining media-specific management information has
  202.    shown the need to distinguish between the multiple sub-layers beneath
  203.    the internetwork-layer.  In addition, there is a need to manage these
  204.    sub-layers in devices (e.g., MAC-layer bridges) which are unaware of
  205.    which, if any, internetwork protocols run over these sub-layers.  As
  206.    such, a model of having a single conceptual row in the interfaces
  207.    table (MIB-II's ifTable) represent a whole interface underneath the
  208.    internetwork-layer, and having a single associated media-specific MIB
  209.    module (referenced via the ifType object) is too simplistic.  A
  210.    further problem arises with the value of the ifType object which has
  211.    enumerated values for each type of interface.
  212.  
  213.    Consider, for example, an interface with PPP running over an HDLC
  214.    link which uses a RS232-like connector.  Each of these sub-layers has
  215.    its own media-specific MIB module.  If all of this is represented by
  216.    a single conceptual row in the ifTable, then an enumerated value for
  217.    ifType is needed for that specific combination which maps to the
  218.    specific combination of media-specific MIBs.  Furthermore, there is
  219.    still a lack of a method to describe the relationship of all the
  220.    sub-layers of the MIB stack.
  221.  
  222.    An associated problem is that of upward and downward multiplexing of
  223.  
  224.  
  225.  
  226. McCloghrie & Kastenholz                                         [Page 4]
  227.  
  228. RFC 1573               Interfaces Group Evolution           January 1994
  229.  
  230.  
  231.    the sub-layers.  An example of upward multiplexing is MLP (Multi-
  232.    Link-Procedure) which provides load-sharing over several serial lines
  233.    by appearing as a single point-to-point link to the sub-layer(s)
  234.    above.  An example of downward multiplexing would be several
  235.    instances of PPP, each framed within a separate X.25 virtual circuit,
  236.    all of which run over one fractional T1 channel, concurrently with
  237.    other uses of the T1 link.  The current MIB structure does not allow
  238.    for these sorts of relationships to be described.
  239.  
  240. 3.1.3.  Virtual Circuits
  241.  
  242.    Several of the sub-layers for which media-specific MIB modules have
  243.    been defined are connection oriented (e.g., Frame Relay, X.25).
  244.    Experience has shown that each effort to define such a MIB module
  245.    revisits the question of whether separate conceptual rows in the
  246.    ifTable are needed for each virtual circuit.  Most, if not all, of
  247.    these efforts to date have decided to have all virtual circuits
  248.    reference a single conceptual row in the ifTable.
  249.  
  250. 3.1.4.  Bit, Character, and Fixed-Length Interfaces
  251.  
  252.    RS-232 is an example of a character-oriented sub-layer over which
  253.    (e.g., through use of PPP) IP datagrams can be sent.  Due to the
  254.    packet-based nature of many of the objects in the ifTable, experience
  255.    has shown that it is not appropriate to have a character-oriented
  256.    sub-layer represented by a (whole) conceptual row in the ifTable.
  257.  
  258.    Experience has also shown that it is sometimes desirable to have some
  259.    management information for bit-oriented interfaces, which are
  260.    similarly difficult to represent by a (whole) conceptual row in the
  261.    ifTable.  For example, to manage the channels of a DS1 circuit, where
  262.    only some of the channels are carrying packet-based data.
  263.  
  264.    A further complication is that some subnetwork technologies transmit
  265.    data in fixed length transmission units.  One example of such a
  266.    technology is cell relay, and in particular Asynchronous Transfer
  267.    Mode (ATM), which transmits data in fixed-length cells.  Representing
  268.    such a interface as a packet-based interface produces redundant
  269.    objects if the relationship between the number of packets and the
  270.    number of octets in either direction is fixed by the size of the
  271.    transmission unit (e.g., the size of a cell).
  272.  
  273. 3.1.5.  Counter Size
  274.  
  275.    As the speed of network media increase, the minimum time in which a
  276.    32 bit counter will wrap decreases.  For example, on an Ethernet, a
  277.    stream of back-to-back, full-size packets will cause ifInOctets to
  278.    wrap in just over 57 minutes.  For a T3 line, the minimum wrap-time
  279.  
  280.  
  281.  
  282. McCloghrie & Kastenholz                                         [Page 5]
  283.  
  284. RFC 1573               Interfaces Group Evolution           January 1994
  285.  
  286.  
  287.    is just over 12 minutes.  For FDDI, it will wrap in 5.7 minutes.  For
  288.    a 1-gigabit medium, the counter might wrap in as little as 34
  289.    seconds.  Requiring that interfaces be polled frequently enough not
  290.    to miss a counter wrap will be increasingly problematic.
  291.  
  292. 3.1.6.  Interface Speed
  293.  
  294.    Network speeds are increasing.  The range of ifSpeed is limited to
  295.    reporting a maximum speed of (2**31)-1 bits/second, or approximately
  296.    2.2Gbs.  SONET defines an OC-48 interface, which is defined at
  297.    operating at 48 times 51 Mbs, which is a speed in excess of 2.4gbits.
  298.    Thus, ifSpeed will be of diminishing utility over the next several
  299.    years.
  300.  
  301. 3.1.7.  Multicast/Broadcast Counters
  302.  
  303.    The counters in the ifTable for packets addressed to a multicast or
  304.    the broadcast address, are combined as counters of non-unicast
  305.    packets.  In contrast, the ifExtensions MIB [7] defines one set of
  306.    counters for multicast, and a separate set for broadcast packets.
  307.    With the separate counters, the original combined counters become
  308.    redundant.
  309.  
  310. 3.1.8.  Addition of New ifType values
  311.  
  312.    Over time new ifType enumerated values have been needed for new
  313.    interface types.  With the syntax of ifType being defined in a MIB,
  314.    this requires the new MIB to be re-issued in order to define the new
  315.    values.  In the past, re-issuing of the MIB has occurred only after
  316.    several years.
  317.  
  318. 3.1.9.  ifSpecific
  319.  
  320.    The original definition of the OBJECT IDENTIFIER value of ifSpecific
  321.    was not sufficently clear.  As a result, different implementors have
  322.    used it differently, and confusion has resulted.  Some
  323.    implementations have the value of ifSpecific be the OBJECT IDENTIFIER
  324.    that defines the media-specific MIB, i.e., the "foo" of:
  325.  
  326.           foo OBJECT IDENTIFIER ::= { transmission xxx }
  327.  
  328.    while others have it be the OBJECT IDENTIFIER of the table or entry
  329.    in the appropriate media-specific MIB (e.g. fooTable or fooEntry),
  330.    while still others have it be the OBJECT IDENTIFIER of the index
  331.    object of the table's row, including instance identifier (e.g.,
  332.    fooIfIndex.ifIndex).  A definition based on the latter would not be
  333.    sufficient unless it also allowed for media-specific MIBs which
  334.    include several tables, where each table has its own, different,
  335.  
  336.  
  337.  
  338. McCloghrie & Kastenholz                                         [Page 6]
  339.  
  340. RFC 1573               Interfaces Group Evolution           January 1994
  341.  
  342.  
  343.    indexing.
  344.  
  345. 3.2.  Clarifications/Revisions
  346.  
  347.    The following clarifications and/or revisions are proposed.
  348.  
  349. 3.2.1.  Interface Numbering
  350.  
  351.    One solution to the interface numbering problem would be to redefine
  352.    ifNumber to be the largest value of ifIndex, but the utility of such
  353.    an object is questionable, and such a re-definition would require
  354.    ifNumber to be deprecated.  Thus, an improvement would be to
  355.    deprecate ifNumber and not replace it.  However, the deprecation of
  356.    ifNumber would require a change to that portion of ifIndex's
  357.    definition which refers to ifNumber.  So, since the definition of
  358.    ifIndex must be changed anyway in order to solve the problem, changes
  359.    to ifNumber do not benefit the solution.
  360.  
  361.    The solution adopted in this memo is to delete the requirement that
  362.    the value of ifIndex must be less than the value of ifNumber, and to
  363.    retain ifNumber with its current definition.  It could be argued that
  364.    this is a change in the semantics of ifIndex; however, all existing
  365.    implementations conform to this new definition, and in the interests
  366.    of not requiring changes in existing implementations and in the many
  367.    existing media-specific MIBs, it is proposed that this change does
  368.    not require ifIndex to be deprecated.
  369.  
  370.    This solution also results in the possibility of "holes" in the
  371.    ifTable (i.e., the ifIndex values of conceptual rows in the ifTable
  372.    are not necessarily contiguous), but SNMP's GetNext (and SNMPv2's
  373.    GetBulk) operation easily deals with such holes.  The value of
  374.    ifNumber still represents the number of conceptual rows, which
  375.    increases/decreases as new interfaces are dynamically added/removed.
  376.    The vital constancy requirement is met by requiring that after an
  377.    interface is dynamically removed, its ifIndex value is not re-used
  378.    (by a different dynamically added interface) until after the
  379.    following re-initialization of the network management system.  This
  380.    avoids the need for a priori assignment of ifIndex values for all
  381.    possible interfaces which might be added dynamically.
  382.  
  383.    The exact meaning of a "different" interface is hard to define, and
  384.    there will be gray areas.  One important criterion is that a
  385.    management station, not noticing that an interface has gone away and
  386.    another come into existence, should not be confused when it
  387.    calculates the difference between the counter values retrieved on
  388.    successive polls for a particular ifIndex value.  However, any firm
  389.    definition in this document would likely to turn out to be
  390.    inadequate.  Instead, the following guidelines are offered to allow
  391.  
  392.  
  393.  
  394. McCloghrie & Kastenholz                                         [Page 7]
  395.  
  396. RFC 1573               Interfaces Group Evolution           January 1994
  397.  
  398.  
  399.    implementors to choose what "different" means in their particular
  400.    situation.
  401.  
  402.    A previously-unused value of ifIndex should be assigned to a
  403.    dynamically added interface if:
  404.  
  405.       (1)  the assignment of a previously-used ifIndex value to the
  406.            interface could result in a discontinuity in the values of
  407.            ifTable counters for that value of ifIndex; or,
  408.  
  409.       (2)  an agent has no knowledge of whether the interface is the
  410.            "same" or "different" from a previous interface incarnation.
  411.  
  412.    Because of the restriction of the value of ifIndex to be less than
  413.    ifNumber, interfaces have been numbered with small integer values.
  414.    This has led to the ability by humans to use the ifIndex values as
  415.    (somewhat) user-friendly names for network interfaces (e.g.,
  416.    "interface number 3").  With the relaxation of the restriction on the
  417.    value of ifIndex, there is now the possibility that ifIndex values
  418.    could be assigned as very large numbers (e.g., memory addresses).
  419.    Such numbers would be much less user-friendly.
  420.  
  421.    Therefore, this memo recommends that ifIndex values still be assigned
  422.    as (relatively) small integer values starting at 1, even though the
  423.    values in use at any one time are not necessarily contiguous.  (Note
  424.    that this makes remembering which values have been assigned easy for
  425.    agents which dynamically add new interfaces.)
  426.  
  427.    This proposed change introduces a new problem of its own.
  428.    Previously, there usually was a simple, direct, mapping of interfaces
  429.    to the physical ports on systems.  This mapping would be based on the
  430.    ifIndex value.  However, by removing the previous restrictions on the
  431.    values allowed for ifIndex, along with the interface sub-layer
  432.    concept (see the following section), mapping from interfaces to
  433.    physical ports becomes increasingly problematic.
  434.  
  435.    To address this issue, a new object, ifName, is added to the MIB.
  436.    This object contains the device's name for the interface of which the
  437.    relevant entry in the ifTable is a component.  For example, if a
  438.    router has an interface named wan1, which is composed of PPP running
  439.    over an RS-232 port, the ifName objects for the corresponding PPP and
  440.    RS-232 entries in the ifTable will contain the string "wan1".
  441.  
  442. 3.2.2.  Interface Sub-Layers
  443.  
  444.    One possible but not recommended solution to the problem of
  445.    representing multiple sub-layers would be to retain the concept of
  446.    one conceptual row for all the sub-layers of an interface and have
  447.  
  448.  
  449.  
  450. McCloghrie & Kastenholz                                         [Page 8]
  451.  
  452. RFC 1573               Interfaces Group Evolution           January 1994
  453.  
  454.  
  455.    each media-specific MIB module identify its "superior" and
  456.    "subordinate" sub-layers through OBJECT IDENTIFIER "pointers".  The
  457.    drawbacks of this scheme are: 1) the superior/subordinate pointers
  458.    are contained in the media-specific MIB modules, and thus, a manager
  459.    could not learn the structure of an interface, without inspecting
  460.    multiple pointers in different MIB modules; this is overly complex
  461.    and only possible if the manager has knowledge of all the relevant
  462.    media-specific MIB modules; 2) current MIB modules would all need to
  463.    be retrofitted with these new "pointers"; 3) this scheme does not
  464.    adequately address the problem of upward and downward multiplexing;
  465.    and 4) enumerated values of ifType are needed for each combination of
  466.    sub-layers.
  467.  
  468.    Another possible but not recommended scheme would be to retain the
  469.    concept of one conceptual row for all the sub-layers of an interface
  470.    and have a new separate MIB table to identify the "superior" and
  471.    "subordinate" sub-layers which contain OBJECT IDENTIFIER "pointers"
  472.    to media-specific MIB module(s) for each sub-layer.  Effectively, one
  473.    conceptual row in the ifTable would represent each combination of
  474.    sub-layers between the internetwork-layer and the wire.  While this
  475.    scheme has fewer drawbacks, it does not support downward
  476.    multiplexing, such as PPP over MLP; since MLP makes two (or more)
  477.    serial lines appear to the layers above as a single physical
  478.    interface, PPP over MLP should appear to the internetwork-layer as a
  479.    single interface.  However, this scheme would result in two (or more)
  480.    conceptual rows in the ifTable and the internetwork-layer would run
  481.    over both of them.  This scheme also requires enumerated values of
  482.    ifType for each combination of sub-layers.
  483.  
  484.    The solution adopted in this memo is to have an individual conceptual
  485.    row in the ifTable to represent each sub-layer and have a new
  486.    separate MIB table (the ifStackTable, see section 5 of this memo) to
  487.    identify the "superior" and "subordinate" sub-layers through INTEGER
  488.    "pointers" to the appropriate conceptual rows in the ifTable.  This
  489.    solution supports both upward and downward multiplexing.  It also
  490.    allows the IANAIfType to Media-Specific MIB mapping to identify the
  491.    media-specific MIB module for each sub- layer.  The new table
  492.    (ifStackTable) need be referenced only to obtain information about
  493.    layering.  Enumerated values for ifType are required for each sub-
  494.    layer only, not for combinations of them.
  495.  
  496.    However, this solution does require that the descriptions of some
  497.    objects in the ifTable (specifically, ifType, ifPhysAddress,
  498.    ifInUcastPkts, and ifOutUcastPkts) be generalized so as to apply to
  499.    any sub-layer (rather than only to a sub-layer immediately beneath
  500.    the network layer, as at present).  It also requires that some
  501.    objects (specifically, ifSpeed) need to have appropriate values
  502.    identified for use when a generalized definition does not apply to a
  503.  
  504.  
  505.  
  506. McCloghrie & Kastenholz                                         [Page 9]
  507.  
  508. RFC 1573               Interfaces Group Evolution           January 1994
  509.  
  510.  
  511.    particular sub-layer.
  512.  
  513.    In addition, this adopted solution makes no requirement that a
  514.    device, in which a sub-layer is instrumented by a conceptual row of
  515.    the ifTable, be aware of whether an internetwork protocol runs on top
  516.    of (i.e., at some layer above) that sub-layer.  In fact, the counters
  517.    of packets received on an interface are defined as counting the
  518.    number "delivered to a higher-layer protocol".  This meaning of
  519.    "higher-layer" includes:
  520.  
  521.       (1)  Delivery to a forwarding module which accepts
  522.            packets/frames/octets and forwards them on at the same
  523.            protocol layer.  For example, for the purposes of this
  524.            definition, the forwarding module of a MAC-layer bridge is
  525.            considered as a "higher-layer" to the MAC-layer of each port
  526.            on the bridge.
  527.  
  528.       (2)  Delivery to a higher sub-layer within a interface stack.  For
  529.            example, for the purposes of this definition, if a PPP module
  530.            operated directly over a serial interface, the PPP module
  531.            would be considered the higher sub-layer to the serial
  532.            interface.
  533.  
  534.       (3)  Delivery to a higher protocol layer which does not do packet
  535.            forwarding for sub-layers that are "at the top of" the
  536.            interface stack.  For example, for the purposes of this
  537.            definition, the local IP module would be considered the
  538.            higher layer to a SLIP serial interface.
  539.  
  540.    Similarly, for output, the counters of packets transmitted out an
  541.    interface are defined as counting the number "that higher-level
  542.    protocols requested to be transmitted".  This meaning of "higher-
  543.    layer" includes:
  544.  
  545.       (1)  A forwarding module, at the same protocol layer, which
  546.            transmits packets/frames/octets that were received on an
  547.            different interface.  For example, for the purposes of this
  548.            definition, the forwarding module of a MAC-layer bridge is
  549.            considered as a "higher-layer" to the MAC-layer of each port
  550.            on the bridge.
  551.  
  552.       (2)  The next higher sub-layer within an interface stack.  For
  553.            example, for the purposes of this definition, if a PPP module
  554.            operated directly over a serial interface, the PPP module
  555.            would be a "higher layer" to the serial interface.
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. McCloghrie & Kastenholz                                        [Page 10]
  563.  
  564. RFC 1573               Interfaces Group Evolution           January 1994
  565.  
  566.  
  567.       (3)  For sub-layers that are "at the top of" the interface stack,
  568.            a higher element in the network protocol stack.  For example,
  569.            for the purposes of this definition, the local IP module
  570.            would be considered the higher layer to an Ethernet
  571.            interface.
  572.  
  573. 3.2.3.  Guidance on Defining Sub-layers
  574.  
  575.    The designer of a media-specific MIB must decide whether to divide
  576.    the interface into sub-layers, and if so, how to make the divisions.
  577.    The following guidance is offered to assist the media-specific MIB
  578.    designer in these decisions.
  579.  
  580.    In general, the number of entries in the ifTable should be kept to
  581.    the minimum required for network management.  In particular, a group
  582.    of related interfaces should be treated as a single interface with
  583.    one entry in the ifTable providing that:
  584.  
  585.       (1)  None of the group of interfaces performs multiplexing for any
  586.            other interface in the agent,
  587.  
  588.       (2)  There is a meaningful and useful way for all of the ifTable's
  589.            information (e.g., the counters, and the status variables),
  590.            and all of the ifTable's capabilities (e.g., write access to
  591.            ifAdminStatus), to apply to the group of interfaces as a
  592.            whole.
  593.  
  594.    Under these circumstances, there should be one entry in the ifTable
  595.    for such a group of interfaces, and any internal structure which
  596.    needs to be represented to network management should be captured in a
  597.    MIB module specific to the particular type of interface.
  598.  
  599.    Note that application of bullet 2 above to the ifTable's ifType
  600.    object requires that there is a meaningful media-specific MIB and a
  601.    meaningful ifType value which apply to the group of interfaces as a
  602.    whole.  For example, it is not appropriate to treat an HDLC sub-layer
  603.    and an RS-232 sub-layer as a single ifTable entry when the media-
  604.    specific MIBs and the ifType values for HDLC and RS-232 are separate
  605.    (rather than combined).
  606.  
  607.    Note that the sub-layers of an interface on one device will sometimes
  608.    be different to the sub-layers of the interconnected interface of
  609.    another device.  A simple example of this is a frame-relay DTE
  610.    interface which connects to a frameRelayService interface, where the
  611.    DTE interface has a different ifType value and media-specific MIB to
  612.    the DCE interface.
  613.  
  614.    Also note that a media-specific MIB may mandate that a particular
  615.  
  616.  
  617.  
  618. McCloghrie & Kastenholz                                        [Page 11]
  619.  
  620. RFC 1573               Interfaces Group Evolution           January 1994
  621.  
  622.  
  623.    ifTable counter does not apply and that its value must always be 0,
  624.    signifying that the applicable event can not and does not occur for
  625.    that type of interface; for example, ifInMulticastPkts and
  626.    ifOutMulticastPkts on an interface type which has no multicast
  627.    capability.  In other circumstances, an agent must not always return
  628.    0 for any counter just because its implementation is incapable of
  629.    detecting occurrences of the particular event; instead, it must
  630.    return a noSuchName/noSuchObject error/exception when queried for the
  631.    counter, even if this prevents the implementation from complying with
  632.    the relevant MODULE-COMPLIANCE macro.
  633.  
  634.    These guidelines are just that - guidelines.  The designer of a
  635.    media-specific MIB is free to lay out the MIB in whatever SMI
  636.    conformant manner is desired.  However, in so doing, the media-
  637.    specific MIB MUST completely specify the sub-layering model used for
  638.    the MIB, and provide the assumptions, reasoning, and rationale used
  639.    to develop that model.
  640.  
  641. 3.2.4.  Virtual Circuits
  642.  
  643.    This memo strongly recommends that connection-oriented sub-layers do
  644.    not have a conceptual row in the ifTable for each virtual circuit.
  645.    This avoids the proliferation of conceptual rows, especially those
  646.    which have considerable redundant information.  (Note, as a
  647.    comparison, that connection-less sub-layers do not have conceptual
  648.    rows for each remote address.)  There may, however, be circumstances
  649.    under which it is appropriate for a virtual circuit of a connection-
  650.    oriented sub-layer to have its own conceptual row in the ifTable; an
  651.    example of this might be PPP over an X.25 virtual circuit.  The MIB
  652.    in section 6 of this memo supports such circumstances.
  653.  
  654.    If a media-specific MIB wishes to assign an entry in the ifTable to
  655.    each virtual circuit, the MIB designer must present the rationale for
  656.    this decision in the media-specific MIB's specification.
  657.  
  658. 3.2.5.  Bit, Character, and Fixed-Length Interfaces
  659.  
  660.    About half the objects in the ifTable are applicable to every type of
  661.    interface: packet-oriented, character-oriented, and bit-oriented.  Of
  662.    the other half, two are applicable to both character-oriented and
  663.    packet-oriented interfaces, and the rest are applicable only to
  664.    packet-oriented interfaces.  Thus, while it is desirable for
  665.    consistency to be able to represent any/all types of interfaces in
  666.    the ifTable, it is not possible to implement the full ifTable for
  667.    bit- and character-oriented sub-layers.
  668.  
  669.    One possible but not recommended solution to this problem would be to
  670.    split the ifTable into two (or more) new MIB tables, one of which
  671.  
  672.  
  673.  
  674. McCloghrie & Kastenholz                                        [Page 12]
  675.  
  676. RFC 1573               Interfaces Group Evolution           January 1994
  677.  
  678.  
  679.    would contain objects that are relevant only to packet-oriented
  680.    interfaces (e.g., PPP), and another that may be used by all
  681.    interfaces.  This is highly undesirable since it would require
  682.    changes in every agent implementing the ifTable (i.e., just about
  683.    every existing SNMP agent).
  684.  
  685.    The solution adopted in this memo builds upon the fact that
  686.    compliance statements in SNMPv2 (in contrast to SNMPv1) refer to
  687.    object groups, where object groups are explicitly defined by listing
  688.    the objects they contain.  Thus, in SNMPv2, multiple compliance
  689.    statements can be specified, one for all interfaces and additional
  690.    ones for specific types of interfaces.  The separate compliance
  691.    statements can be based on separate object groups, where the object
  692.    group for all interfaces can contain only those objects from the
  693.    ifTable which are appropriate for every type of interfaces.  Using
  694.    this solution, every sub-layer can have its own conceptual row in the
  695.    ifTable.
  696.  
  697.    Thus, section 6 of this memo contains definitions of the objects of
  698.    the existing 'interfaces' group of MIB-II, in a manner which is both
  699.    SNMPv2-compliant and semantically-equivalent to the existing MIB-II
  700.    definitions.  With equivalent semantics, and with the BER ("on the
  701.    wire") encodings unchanged, these definitions retain the same OBJECT
  702.    IDENTIFIER values as assigned by MIB-II.  Thus, in general, no
  703.    rewrite of existing agents which conform to MIB-II and the
  704.    ifExtensions MIB is required.
  705.  
  706.    In addition, this memo defines several object groups for the purposes
  707.    of defining which objects apply to which types of interface:
  708.  
  709.       (1)  the ifGeneralGroup.  This group contains those objects
  710.            applicable to all types of network interfaces, including
  711.            bit-oriented interfaces.
  712.  
  713.       (2)  the ifPacketGroup.  This group contains those objects
  714.            applicable to packet-oriented network interfaces.
  715.  
  716.       (3)  the ifFixedLengthGroup.  This group contains the objects
  717.            applicable not only to character-oriented interfaces, such as
  718.            RS-232, but also to those subnetwork technologies, such as
  719.            cell-relay/ATM, which transmit data in fixed length
  720.            transmission units.  As well as the octet counters, there are
  721.            also a few other counters (e.g., the error counters) which
  722.            are useful for this type of interface, but are currently
  723.            defined as being packet-oriented.  To accommodate this, the
  724.            definitions of these counters are generalized to apply to
  725.            character-oriented interfaces and fixed-length-transmission
  726.            interfaces.
  727.  
  728.  
  729.  
  730. McCloghrie & Kastenholz                                        [Page 13]
  731.  
  732. RFC 1573               Interfaces Group Evolution           January 1994
  733.  
  734.  
  735.    It should be noted that the octet counters in the ifTable aggregate
  736.    octet counts for unicast and non-unicast packets into a single octet
  737.    counter per direction (received/transmitted).  Thus, with the above
  738.    definition of fixed-length-transmission interfaces, where such
  739.    interfaces which support non-unicast packets, separate counts of
  740.    unicast and multicast/broadcast transmissions can only be maintained
  741.    in a media-specific MIB module.
  742.  
  743. 3.2.6.  Counter Size
  744.  
  745.    Two approaches to addressing the shrinking minimum counter-wrap time
  746.    problem were evaluated.  Counters could be scaled, for example,
  747.    ifInOctets could be changed to count received octets in, e.g., 1024
  748.    byte blocks.  Alternatively, the size of the counter could be
  749.    increased.
  750.  
  751.    Scaling the counters was rejected.  While it provides acceptable
  752.    performance at high count rates, at low rates it suffers.  If there
  753.    is little traffic on an interface, there might be a significant
  754.    interval before enough counts occur to cause a counter to be
  755.    incremented.  Traffic would then appear to be very bursty, leading to
  756.    incorrect conclusions of the network's performance.
  757.  
  758.    The alternative, which this memo adopts, is to provide expanded, 64
  759.    bit, counters.  These counters are provided in new "high capacity"
  760.    groups,
  761.  
  762.    The old, 32-bit, counters have not been deprecated.  The 64-bit
  763.    counters are to be used only when the 32-bit counters do not provide
  764.    enough capacity; that is, the 32 bit counters could wrap too fast.
  765.  
  766.    For interfaces that operate at 20,000,000 (20 million) bits per
  767.    second or less, 32-bit byte and packet counters MUST be used.  For
  768.    interfaces that operate faster than 20,000,000 bits/second, and
  769.    slower than 650,000,000 bits/second, 32-bit packet counters MUST be
  770.    used and 64-bit octet counters MUST be used.  For interfaces that
  771.    operate at 650,000,000 bits/second or faster, both 64-bit packet
  772.    counters AND 64-bit octet counters MUST be used.
  773.  
  774.    These speed steps were chosen as reasonable compromises based on the
  775.    following:
  776.  
  777.       (1)  The cost of maintaining 64-bit counters is relatively high,
  778.            so minimizing the number of agents which must support them is
  779.            desirable.  Common interfaces (such as Ethernet) should not
  780.            require them.
  781.  
  782.  
  783.  
  784.  
  785.  
  786. McCloghrie & Kastenholz                                        [Page 14]
  787.  
  788. RFC 1573               Interfaces Group Evolution           January 1994
  789.  
  790.  
  791.       (2)  64-bit counters are a new feature, introduced in SNMPv2.  It
  792.            is reasonable to expect that support for them will be spotty
  793.            for the immediate future.  Thus, we wish to limit them to as
  794.            few systems as possible.  This, in effect, means that 64-bit
  795.            counters should be limited to higher speed interfaces.
  796.            Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps) are
  797.            fairly wide-spread so it seems reasonable to not require 64-
  798.            bit counters for these interfaces.
  799.  
  800.       (3)  The 32-bit octet counters will wrap in the following times,
  801.            for the following interfaces (when transmitting maximum-sized
  802.            packets back-to-back):
  803.  
  804.            -   Ethernet: 57 minutes,
  805.  
  806.            -   16 megabit Token Ring: 36 minutes,
  807.  
  808.            -   A US T3 line (45 megabits): 12 minutes,
  809.  
  810.            -   FDDI: 5.7 minutes
  811.  
  812.       (4)  The 32-bit packet counters wraps in about 57 minutes when
  813.            64-byte packets are transmitted back-to-back on a 650,000,000
  814.            bit/second link.
  815.  
  816.            As an aside, a 1-terabit (1,000 gigabits) link will cause a
  817.            64 bit octet counter to wrap in just under 5 years.
  818.            Conversely, an 81,000,000 terabit/second link is required to
  819.            cause a 64-bit counter to wrap in 30 minutes.  We believe
  820.            that, while technology rapidly marches forward, this link
  821.            speed will not be achieved for at least several years,
  822.            leaving sufficient time to evaluate the introduction of 96
  823.            bit counters.
  824.  
  825.    When 64-bit counters are in use, the 32-bit counters MUST still be
  826.    available.  They will report the low 32-bits of the associated 64-bit
  827.    count (e.g., ifInOctets will report the least significant 32 bits of
  828.    ifHCInOctets).  This enhances inter-operability with existing
  829.    implementations at a very minimal cost to agents.
  830.  
  831.    The new "high capacity" groups are:
  832.  
  833.       (1)  the ifHCFixedLengthGroup for character-oriented/fixed-length
  834.            interfaces, and the ifHCPacketGroup for packet-based
  835.            interfaces; both of these groups include 64 bit counters for
  836.            octets, and
  837.  
  838.  
  839.  
  840.  
  841.  
  842. McCloghrie & Kastenholz                                        [Page 15]
  843.  
  844. RFC 1573               Interfaces Group Evolution           January 1994
  845.  
  846.  
  847.       (2)  the ifVHCPacketGroup for packet-based interfaces; this group
  848.            includes 64 bit counters for octets and packets.
  849.  
  850. 3.2.7.  Interface Speed
  851.  
  852.    In order to deal with increasing interface speeds, we have added an
  853.    ifHighSpeed object.
  854.  
  855.    This object reports the speed of the interface in 1,000,000 (1
  856.    million) bits/second units.  Thus, the true speed of the interface
  857.    will be the value reported by this object, plus or minus 500,000
  858.    bits/second.
  859.  
  860.    Other alternatives considered were:
  861.  
  862.       (1)  Making the interface speed a 64-bit gauge.  This was rejected
  863.            since the current SMI does not allow such a syntax.
  864.  
  865.            Furthermore, even if 64-bit gauges were available, their use
  866.            would require additional complexity in agents due to an
  867.            increased requirement for 64-bit operations.
  868.  
  869.       (2)  We also considered making "high-32 bit" and "low-32-bit"
  870.            objects which, when combined, would be a 64-bit value.  This
  871.            simply seemed overly complex for what we are trying to do.
  872.  
  873.            Furthermore, a full 64-bits of precision does not seem
  874.            necessary.  The value of ifHighSpeed will be the only report
  875.            of interface speed for interfaces that are faster than
  876.            4,294,967,295 bits per second.  At this speed, the
  877.            granularity of ifHighSpeed will be 1,000,000 bits per second,
  878.            thus the error will be 1/4294, or about 0.02%.  This seems
  879.            reasonable.
  880.  
  881.       (3)  Adding a "scale" object, which would define the units which
  882.            ifSpeed's value is.
  883.  
  884.            This would require two additional objects; one for the
  885.            scaling object, and one to replace the current ifSpeed.  This
  886.            later object is required since the semantics of ifSpeed would
  887.            be significantly altered, and manager stations which do not
  888.            understand the new semantics would be confused.
  889.  
  890. 3.2.8.  Multicast/Broadcast Counters
  891.  
  892.    To avoid the redundancy of counting all non-unicast packets as well
  893.    as having individual multicast and broadcast packet counters, we
  894.    deprecate the use of the non-unicast counters, which can be derived
  895.  
  896.  
  897.  
  898. McCloghrie & Kastenholz                                        [Page 16]
  899.  
  900. RFC 1573               Interfaces Group Evolution           January 1994
  901.  
  902.  
  903.    from the values of the others.
  904.  
  905.    For the output broadcast and multicast counters defined in RFC 1229,
  906.    their definitions varied slightly from the packet counters in the
  907.    ifTable, in that they did not count errors/discarded packets.  To
  908.    align the definitions better, the old counters are deprecated and
  909.    replaced by new definitions.  Counters with 64 bits of range are also
  910.    needed, as explained above.
  911.  
  912. 3.2.9.  Trap Enable
  913.  
  914.    In the multi-layer interface model, each sub-layer for which there is
  915.    an entry in the ifTable can generate linkUp/Down Traps.  Since
  916.    interface state changes would tend to propagate through the interface
  917.    (from top to bottom, or bottom to top), it is likely that several
  918.    traps would be generated for each linkUp/Down occurrence.
  919.  
  920.    It is desirable to provide a mechanism for manager stations to
  921.    control the generation of these traps.  To this end, the
  922.    ifLinkUpDownTrapEnable object has been added.  This object allows
  923.    managers to limit generation of traps to just the sub-layers of
  924.    interest.
  925.  
  926.    The default setting should limit the number of traps generated to one
  927.    per interface per linkUp/Down event.  Furthermore, it seems that the
  928.    conditions that cause these state changes that are of most interest
  929.    to network managers occur at the lowest level of an interface stack.
  930.    Therefore we specify that by default, only the lowest sub-layer of
  931.    the interface generate traps.
  932.  
  933. 3.2.10.  Addition of New ifType values
  934.  
  935.    The syntax of ifType is changed to be a textual convention, such that
  936.    the enumerated integer values are now defined in the textual
  937.    convention, IANAifType, which can be re-specified (with additional
  938.    values) without issuing a new version of this document.  The Internet
  939.    Assigned Number Authority (IANA) is responsible for the assignment of
  940.    all Internet numbers, including various SNMP-related numbers, and
  941.    specifically, new ifType values.  Thus, this document defines two MIB
  942.    modules: one to define the MIB for the 'interfaces' group, and a
  943.    second to define the first version of the IANAifType textual
  944.    convention.  The latter will be periodically re-issued by the IANA.
  945.  
  946. 3.2.11.  InterfaceIndex Textual Convention
  947.  
  948.    A new textual convention, InterfaceIndex, has been defined.  This
  949.    textual convention "contains" all of the semantics of the ifIndex
  950.    object.  This allows other mib modules to easily import the semantics
  951.  
  952.  
  953.  
  954. McCloghrie & Kastenholz                                        [Page 17]
  955.  
  956. RFC 1573               Interfaces Group Evolution           January 1994
  957.  
  958.  
  959.    of ifIndex.
  960.  
  961. 3.2.12.  IfAdminStatus and IfOperStatus
  962.  
  963.    A new state has been added to ifOperStatus: dormant.  This state
  964.    indicates that the relevant interface is not actually in a condition
  965.    to pass packets (i.e., up) but is in a "pending" state, waiting for
  966.    some external event.  For "on-demand" interfaces, this new state
  967.    identifies the situation where the interface is waiting for events to
  968.    place it in the up state.  Examples of such events might be:
  969.  
  970.       (1)  having packets to transmit before establishing a connection
  971.            to a remote system.
  972.  
  973.       (2)  having a remote system establish a connection to the
  974.            interface (e.g., dialing up to a slip-server).
  975.  
  976.    The down state now has two meanings, depending on the value of
  977.    ifAdminStatus.
  978.  
  979.       (1)  If ifAdminStatus is not down and ifOperStatus is down, then a
  980.            fault condition is presumed to exist on the interface.
  981.  
  982.       (2)  If ifAdminStatus is down, then ifOperStatus will normally
  983.            also be down, i.e., there is not (necessarily) a fault
  984.            condition on the interface.
  985.  
  986.    Note that when ifAdminStatus transitions to down, ifOperStatus will
  987.    normally also transition to down.  In this situation, it is possible
  988.    that ifOperStatus's transition will not occur immediately, but rather
  989.    after a small time lag to complete certain operations before going
  990.    "down"; for example, it might need to finish transmitting a packet.
  991.    If a manager station finds that ifAdminStatus is down and
  992.    ifOperStatus is not down for a particular interface, the manager
  993.    station should wait a short while and check again.  If the condition
  994.    still exists only then should it raise an error indication.
  995.    Naturally, it should also ensure that ifLastChange has not changed
  996.    during this interval.
  997.  
  998.    Whenever an interface table entry is created (usually as a result of
  999.    system initialization), the relevant instance of ifAdminStatus is set
  1000.    to down, and presumably ifOperStatus will also be down.
  1001.  
  1002.    An interface may be enabled in two ways: either as a result of
  1003.    explicit management action (e.g., setting ifAdminStatus to up) or as
  1004.    a result of the managed system's initialization process.  When
  1005.    ifAdminStatus changes to the up state, the related ifOperStatus
  1006.    should do one of the following:
  1007.  
  1008.  
  1009.  
  1010. McCloghrie & Kastenholz                                        [Page 18]
  1011.  
  1012. RFC 1573               Interfaces Group Evolution           January 1994
  1013.  
  1014.  
  1015.       (1)  Change to the up state if and only if the interface is able
  1016.            to send and receive packets.
  1017.  
  1018.       (2)  Change to the dormant state if and only if the interface is
  1019.            found to be operable, but the interface is waiting for other,
  1020.            external, events to occur before it can transmit or receive
  1021.            packets.  Presumably when the expected events occur, the
  1022.            interface will then transition to the up state.
  1023.  
  1024.       (3)  Remain in the down state if an error or other fault condition
  1025.            is detected on the interface.
  1026.  
  1027.       (4)  Change to the unknown state if, for some reason, the state of
  1028.            the interface can not be ascertained.
  1029.  
  1030.       (5)  Change to the testing state if some test(s) must be performed
  1031.            on the interface.  Presumably after completion of the test,
  1032.            the interface's state will change to up, dormant, or down, as
  1033.            appropriate.
  1034.  
  1035. 3.2.13.  Traps
  1036.  
  1037.    The exact definition of when linkUp and linkDown traps are generated,
  1038.    has been changed to reflect the changes to ifAdminStatus and
  1039.    ifOperStatus.
  1040.  
  1041.    LinkUp and linkDown traps are generated just after ifOperStatus
  1042.    leaves, or just before it enters, the down state, respectively.  The
  1043.    wording of the conditions under which a linkDown trap is generated
  1044.    was explicitly chosen to allow a node with only one interface to
  1045.    transmit the linkDown trap before that interface goes down.
  1046.  
  1047.    Operational experience seems to indicate that manager stations are
  1048.    most concerned with an interface being in the down state and the fact
  1049.    that this state may indicate a failure.  It seemed most useful to
  1050.    instrument either transitions into/out of the up state or the down
  1051.    state.
  1052.  
  1053.    Instrumenting transitions into or out of the up state has the
  1054.    drawback that an on-demand interface might have many transitions
  1055.    between up and dormant, leading to many linkUp traps and no linkDown
  1056.    traps.  Furthermore, if a node's only interface is the on-demand
  1057.    interface, then a transition to dormant will entail generation of a
  1058.    trap, necessitating bringing the link to the up state (and a linkUp
  1059.    trap)!!
  1060.  
  1061.    On the other hand, instrumenting transitions into or out of the down
  1062.    state has the advantages:
  1063.  
  1064.  
  1065.  
  1066. McCloghrie & Kastenholz                                        [Page 19]
  1067.  
  1068. RFC 1573               Interfaces Group Evolution           January 1994
  1069.  
  1070.  
  1071.       (1)  A transition into the down state will occur when an error is
  1072.            detected on an interface.  Error conditions are presumably of
  1073.            great interest to network managers.
  1074.  
  1075.       (2)  Departing the down state generally indicates that the
  1076.            interface is going to either up or dormant, both of which are
  1077.            considered "healthy" states.
  1078.  
  1079.    Furthermore, it is believed that generarating traps on transitions
  1080.    into or out of the down state is generally consistent with current
  1081.    usage and interpretation of these traps by manager stations.
  1082.  
  1083.    Therefore, this memo defines that it is the transitions into/out of
  1084.    the down state which generate traps.
  1085.  
  1086.    Obviously, if a failure condition is present on a node with a single
  1087.    interface, the linkDown trap will probably not be succesfully
  1088.    transmitted since the interface through which it must be transmitted
  1089.    has failed.
  1090.  
  1091. 3.2.14.  ifSpecific
  1092.  
  1093.    The current definition of ifSpecific is not explicit enough.  The
  1094.    only definition that can both be made explicit and can cover all the
  1095.    useful situations (see section 3.1.9) is to have ifSpecific be the
  1096.    most general value for the media-specific MIB module (the first
  1097.    example given section in 3.1.9).  This effectively makes it redundant
  1098.    because it contains no more information than is provided by ifType.
  1099.    For this reason, ifSpecific has been deprecated.
  1100.  
  1101. 3.3.  Media-Specific MIB Applicability
  1102.  
  1103.    The exact use and semantics of many objects in this MIB are open to
  1104.    some interpretation.  This is a result of the generic nature of this
  1105.    MIB.  It is not always possible to come up with specific,
  1106.    unambiguous, text that covers all cases and yet preserve the generic
  1107.    nature of the MIB.
  1108.  
  1109.    Therefore, it is incumbent upon a media-specific MIB designer to,
  1110.    wherever necessary, clarify the use of the objects in this MIB with
  1111.    respect to the media-specific MIB.
  1112.  
  1113.    Specific areas of clarification include:
  1114.  
  1115.    Layering Model
  1116.         The media-specific MIB designer MUST completely and
  1117.         unambiguously specify the layering model used.  Each
  1118.         individual sub-layer must be identified.
  1119.  
  1120.  
  1121.  
  1122. McCloghrie & Kastenholz                                        [Page 20]
  1123.  
  1124. RFC 1573               Interfaces Group Evolution           January 1994
  1125.  
  1126.  
  1127.    Virtual Circuits
  1128.         The media-specific MIB designer MUST specify whether virtual
  1129.         circuits are assigned entries in the ifTable or not.  If they
  1130.         are, compelling rationale must be presented.
  1131.  
  1132.    ifTestTable
  1133.         The media-specific MIB designer MUST specify the
  1134.         applicability of the ifTestTable.
  1135.  
  1136.    ifRcvAddressTable
  1137.         The media-specific MIB designer MUST specify the
  1138.         applicability of the ifRcvAddressTable.
  1139.  
  1140.    ifType
  1141.         For each of the ifType values to which the media-specific MIB
  1142.         applies, it must specify the mapping of ifType values to
  1143.         media-specific MIB module(s) and instances of MIB objects
  1144.         within those modules.
  1145.  
  1146.    However, wherever this interface MIB is specific in the semantics,
  1147.    DESCRIPTION, or applicability of objects, the media-specific MIB
  1148.    designer MUST NOT change said semantics, DESCRIPTION, or
  1149.    applicability.
  1150.  
  1151. 4.  Overview
  1152.  
  1153.    This MIB consists of 5 tables:
  1154.  
  1155.    ifTable
  1156.         This table is the ifTable from MIB-II.
  1157.  
  1158.    ifXTable
  1159.         This table contains objects that have been added to the
  1160.         Interface MIB as a result of the Interface Evolution effort,
  1161.         or replacements for objects of the original, MIB-II, ifTable
  1162.         that were deprecated because the semantics of said objects
  1163.         have significantly changed.  This table also contains objects
  1164.         that were previously in the ifExtnsTable.
  1165.  
  1166.    ifStackTable
  1167.         This table contains objects that define the relationships
  1168.         among the sub-layers of an interface.
  1169.  
  1170.    ifTestTable
  1171.         This table contains objects that are used to perform tests on
  1172.         interfaces.  This table is a generic table.  The designers of
  1173.         media-specific MIBs must define exactly how this table
  1174.         applies to their specific MIB.
  1175.  
  1176.  
  1177.  
  1178. McCloghrie & Kastenholz                                        [Page 21]
  1179.  
  1180. RFC 1573               Interfaces Group Evolution           January 1994
  1181.  
  1182.  
  1183.         This table replaces the interface test table defined in
  1184.         RFC1229 [7].  The significant change is the replacement of
  1185.         the ifExtnsTestCommunity (and ifExtnsTestContext which would
  1186.         also have been required for SNMPv2) and ifExtnsTestRequestId
  1187.         objects, by the new ifTestId, ifTestStatus, and ifTestOwner
  1188.         objects.
  1189.  
  1190.    ifRcvAddressTable
  1191.         This table contains objects that are used to define the
  1192.         media-level addresses which this interface will receive.
  1193.         This table is a generic table.  The designers of media-
  1194.         specific MIBs must define exactly how this table applies to
  1195.         their specific MIB.
  1196.  
  1197. 5.  IANAifType Definition
  1198.  
  1199.    IANAifType-MIB DEFINITIONS ::= BEGIN
  1200.  
  1201.    IMPORTS
  1202.        MODULE-IDENTITY, OBJECT-TYPE        FROM SNMPv2-SMI
  1203.        TEXTUAL-CONVENTION                  FROM SNMPv2-TC;
  1204.  
  1205.    ianaifType MODULE-IDENTITY
  1206.        LAST-UPDATED "9311082155Z"
  1207.        ORGANIZATION "IANA"
  1208.        CONTACT-INFO
  1209.  
  1210.                   "        Internet Assigned Numbers Authority
  1211.  
  1212.                    Postal: USC/Information Sciences Institute
  1213.                            4676 Admiralty Way, Marina del Rey, CA 90292
  1214.  
  1215.                    Tel:    +1  310 822 1511
  1216.                    E-Mail: iana@isi.edu"
  1217.        DESCRIPTION
  1218.                "The MIB module which defines the IANAifType textual
  1219.                convention, and thus the enumerated values of the
  1220.                ifType object defined in MIB-II's ifTable."
  1221.        ::= { mib-2 30 }
  1222.  
  1223.  
  1224.    IANAifType ::= TEXTUAL-CONVENTION
  1225.        STATUS       current
  1226.        DESCRIPTION
  1227.                "This data type is used as the syntax of the ifType
  1228.                object in the (updated) definition of MIB-II's
  1229.                ifTable.
  1230.  
  1231.  
  1232.  
  1233.  
  1234. McCloghrie & Kastenholz                                        [Page 22]
  1235.  
  1236. RFC 1573               Interfaces Group Evolution           January 1994
  1237.  
  1238.  
  1239.                The definition of this textual convention with the
  1240.                addition of newly assigned values is published
  1241.                periodically by the IANA, in either the Assigned
  1242.                Numbers RFC, or some derivative of it specific to
  1243.                Internet Network Management number assignments.  (The
  1244.                latest arrangements can be obtained by contacting the
  1245.                IANA.)
  1246.  
  1247.                Requests for new values should be made to IANA via
  1248.                email (iana@isi.edu).
  1249.  
  1250.                The relationship between the assignment of ifType
  1251.                values and of OIDs to particular media-specific MIBs
  1252.                is solely the purview of IANA and is subject to change
  1253.                without notice.  Quite often, a media-specific MIB's
  1254.                OID-subtree assignment within MIB-II's 'transmission'
  1255.                subtree will be the same as its ifType value.
  1256.                However, in some circumstances this will not be the
  1257.                case, and implementors must not pre-assume any
  1258.                specific relationship between ifType values and
  1259.                transmission subtree OIDs."
  1260.        SYNTAX  INTEGER {
  1261.                    other(1),          -- none of the following
  1262.                    regular1822(2),
  1263.                    hdh1822(3),
  1264.                    ddnX25(4),
  1265.                    rfc877x25(5),
  1266.                    ethernetCsmacd(6),
  1267.                    iso88023Csmacd(7),
  1268.                    iso88024TokenBus(8),
  1269.                    iso88025TokenRing(9),
  1270.                    iso88026Man(10),
  1271.                    starLan(11),
  1272.                    proteon10Mbit(12),
  1273.                    proteon80Mbit(13),
  1274.                    hyperchannel(14),
  1275.                    fddi(15),
  1276.                    lapb(16),
  1277.                    sdlc(17),
  1278.                    ds1(18),           -- DS1/E1 (RFC 1406)
  1279.                    e1(19),            -- obsolete
  1280.                    basicISDN(20),
  1281.                    primaryISDN(21),
  1282.                    propPointToPointSerial(22), -- proprietary serial
  1283.                    ppp(23),
  1284.                    softwareLoopback(24),
  1285.                    eon(25),            -- CLNP over IP (RFC 1070)
  1286.                    ethernet3Mbit(26),
  1287.  
  1288.  
  1289.  
  1290. McCloghrie & Kastenholz                                        [Page 23]
  1291.  
  1292. RFC 1573               Interfaces Group Evolution           January 1994
  1293.  
  1294.  
  1295.                    nsip(27),           -- XNS over IP
  1296.                    slip(28),           -- generic SLIP
  1297.                    ultra(29),          -- ULTRA technologies
  1298.                    ds3(30),            -- T-3
  1299.                    sip(31),            -- SMDS
  1300.                    frameRelay(32),    -- DTE only
  1301.                    rs232(33),
  1302.                    para(34),           -- parallel-port
  1303.                    arcnet(35),         -- arcnet
  1304.                    arcnetPlus(36),     -- arcnet plus
  1305.                    atm(37),            -- ATM cells
  1306.                    miox25(38),
  1307.                    sonet(39),          -- SONET or SDH
  1308.                    x25ple(40),
  1309.                    iso88022llc(41),
  1310.                    localTalk(42),
  1311.                    smdsDxi(43),
  1312.                    frameRelayService(44),  -- Frame relay DCE
  1313.                    v35(45),
  1314.                    hssi(46),
  1315.                    hippi(47),
  1316.                    modem(48),          -- Generic modem
  1317.                    aal5(49),           -- AAL5 over ATM
  1318.                    sonetPath(50),
  1319.                    sonetVT(51),
  1320.                    smdsIcip(52),       -- SMDS InterCarrier Interface
  1321.                    propVirtual(53),    -- proprietary virtual/internal
  1322.                    propMultiplexor(54) -- proprietary multiplexing
  1323.                }
  1324.  
  1325.    END
  1326.  
  1327. 6.  Interfaces Group Definitions
  1328.  
  1329.    IF-MIB DEFINITIONS ::= BEGIN
  1330.  
  1331.    IMPORTS
  1332.        MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32,
  1333.        Integer32, TimeTicks,
  1334.        NOTIFICATION-TYPE                        FROM SNMPv2-SMI
  1335.        TEXTUAL-CONVENTION, DisplayString,
  1336.        PhysAddress, TruthValue, RowStatus,
  1337.        AutonomousType, TestAndIncr              FROM SNMPv2-TC
  1338.        MODULE-COMPLIANCE, OBJECT-GROUP          FROM SNMPv2-CONF
  1339.        IANAifType                               FROM IANAifType-MIB
  1340.        interfaces                               FROM RFC-1213;
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. McCloghrie & Kastenholz                                        [Page 24]
  1347.  
  1348. RFC 1573               Interfaces Group Evolution           January 1994
  1349.  
  1350.  
  1351.    ifMIB MODULE-IDENTITY
  1352.        LAST-UPDATED "9311082155Z"
  1353.        ORGANIZATION "IETF Interfaces MIB Working Group"
  1354.        CONTACT-INFO
  1355.  
  1356.                   "        Keith McCloghrie
  1357.  
  1358.                    Postal: Hughes LAN Systems
  1359.                            1225 Charleston Road, Mountain View, CA 94043
  1360.  
  1361.                    Tel:    +1 415 966 7934
  1362.                    E-Mail: kzm@hls.com
  1363.  
  1364.  
  1365.                            Frank Kastenholz
  1366.  
  1367.                    Postal: FTP Software
  1368.                            2 High Street, North Andover, MA 01845
  1369.  
  1370.                    Tel:    +1 508 685 4000
  1371.                    E-Mail: kasten@ftp.com"
  1372.        DESCRIPTION
  1373.                "The MIB module to describe generic objects for
  1374.                network interface sub-layers.  This MIB is an updated
  1375.                version of MIB-II's ifTable, and incorporates the
  1376.                extensions defined in RFC 1229."
  1377.        ::= { mib-2 31 }
  1378.  
  1379.    ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 }
  1380.  
  1381.    -- OwnerString has the same semantics as used in RFC 1271
  1382.  
  1383.    OwnerString ::= TEXTUAL-CONVENTION
  1384.        DISPLAY-HINT "255a"
  1385.        STATUS       current
  1386.        DESCRIPTION
  1387.                "This data type is used to model an administratively
  1388.                assigned name of the owner of a resource.  This
  1389.                information is taken from the NVT ASCII character set.
  1390.                It is suggested that this name contain one or more of
  1391.                the following: ASCII form of the manager station's
  1392.                transport address, management station name (e.g.,
  1393.                domain name), network management personnel's name,
  1394.                location, or phone number.  In some cases the agent
  1395.                itself will be the owner of an entry.  In these cases,
  1396.                this string shall be set to a string starting with
  1397.                'agent'."
  1398.        SYNTAX       OCTET STRING (SIZE(0..255))
  1399.  
  1400.  
  1401.  
  1402. McCloghrie & Kastenholz                                        [Page 25]
  1403.  
  1404. RFC 1573               Interfaces Group Evolution           January 1994
  1405.  
  1406.  
  1407.    -- InterfaceIndex contains the semantics of ifIndex and
  1408.    -- should be used for any objects defined on other mib
  1409.    -- modules that need these semantics.
  1410.  
  1411.    InterfaceIndex ::= TEXTUAL-CONVENTION
  1412.        DISPLAY-HINT "d"
  1413.        STATUS       current
  1414.        DESCRIPTION
  1415.                "A unique value, greater than zero, for each interface
  1416.                or interface sub-layer in the managed system.  It is
  1417.                recommended that values are assigned contiguously
  1418.                starting from 1.  The value for each interface sub-
  1419.                layer must remain constant at least from one re-
  1420.                initialization of the entity's network management
  1421.                system to the next re-initialization."
  1422.        SYNTAX       Integer32
  1423.  
  1424.    ifNumber  OBJECT-TYPE
  1425.        SYNTAX      Integer32
  1426.        MAX-ACCESS  read-only
  1427.        STATUS      current
  1428.        DESCRIPTION
  1429.                "The number of network interfaces (regardless of their
  1430.                current state) present on this system."
  1431.        ::= { interfaces 1 }
  1432.  
  1433.  
  1434.    -- the Interfaces table
  1435.  
  1436.    -- The Interfaces table contains information on the entity's
  1437.    -- interfaces.  Each sub-layer below the internetwork-layer
  1438.    -- of a network interface is considered to be an interface.
  1439.  
  1440.    ifTable OBJECT-TYPE
  1441.        SYNTAX      SEQUENCE OF IfEntry
  1442.        MAX-ACCESS  not-accessible
  1443.        STATUS      current
  1444.        DESCRIPTION
  1445.                "A list of interface entries.  The number of entries
  1446.                is given by the value of ifNumber."
  1447.        ::= { interfaces 2 }
  1448.  
  1449.    ifEntry OBJECT-TYPE
  1450.        SYNTAX      IfEntry
  1451.        MAX-ACCESS  not-accessible
  1452.        STATUS      current
  1453.        DESCRIPTION
  1454.                "An entry containing management information applicable
  1455.  
  1456.  
  1457.  
  1458. McCloghrie & Kastenholz                                        [Page 26]
  1459.  
  1460. RFC 1573               Interfaces Group Evolution           January 1994
  1461.  
  1462.  
  1463.                to a particular interface."
  1464.        INDEX   { ifIndex }
  1465.        ::= { ifTable 1 }
  1466.  
  1467.    IfEntry ::=
  1468.        SEQUENCE {
  1469.            ifIndex                 InterfaceIndex,
  1470.            ifDescr                 DisplayString,
  1471.            ifType                  IANAifType,
  1472.            ifMtu                   Integer32,
  1473.            ifSpeed                 Gauge32,
  1474.            ifPhysAddress           PhysAddress,
  1475.            ifAdminStatus           INTEGER,
  1476.            ifOperStatus            INTEGER,
  1477.            ifLastChange            TimeTicks,
  1478.            ifInOctets              Counter32,
  1479.            ifInUcastPkts           Counter32,
  1480.            ifInNUcastPkts          Counter32,  -- deprecated
  1481.            ifInDiscards            Counter32,
  1482.            ifInErrors              Counter32,
  1483.            ifInUnknownProtos       Counter32,
  1484.            ifOutOctets             Counter32,
  1485.            ifOutUcastPkts          Counter32,
  1486.            ifOutNUcastPkts         Counter32,  -- deprecated
  1487.            ifOutDiscards           Counter32,
  1488.            ifOutErrors             Counter32,
  1489.            ifOutQLen               Gauge32,    -- deprecated
  1490.            ifSpecific              OBJECT IDENTIFIER -- deprecated
  1491.        }
  1492.  
  1493.  
  1494.    ifIndex OBJECT-TYPE
  1495.        SYNTAX      InterfaceIndex
  1496.        MAX-ACCESS  read-only
  1497.        STATUS      current
  1498.        DESCRIPTION
  1499.                "A unique value, greater than zero, for each
  1500.                interface.  It is recommended that values are assigned
  1501.                contiguously starting from 1.  The value for each
  1502.                interface sub-layer must remain constant at least from
  1503.                one re-initialization of the entity's network
  1504.                management system to the next re-initialization."
  1505.        ::= { ifEntry 1 }
  1506.  
  1507.    ifDescr OBJECT-TYPE
  1508.        SYNTAX      DisplayString (SIZE (0..255))
  1509.        MAX-ACCESS  read-only
  1510.        STATUS      current
  1511.  
  1512.  
  1513.  
  1514. McCloghrie & Kastenholz                                        [Page 27]
  1515.  
  1516. RFC 1573               Interfaces Group Evolution           January 1994
  1517.  
  1518.  
  1519.        DESCRIPTION
  1520.                "A textual string containing information about the
  1521.                interface.  This string should include the name of the
  1522.                manufacturer, the product name and the version of the
  1523.                interface hardware/software."
  1524.        ::= { ifEntry 2 }
  1525.  
  1526.    ifType OBJECT-TYPE
  1527.        SYNTAX      IANAifType
  1528.        MAX-ACCESS  read-only
  1529.        STATUS      current
  1530.        DESCRIPTION
  1531.                "The type of interface.  Additional values for ifType
  1532.                are assigned by the Internet Assigned Numbers
  1533.                Authority (IANA), through updating the syntax of the
  1534.                IANAifType textual convention."
  1535.        ::= { ifEntry 3 }
  1536.  
  1537.    ifMtu OBJECT-TYPE
  1538.        SYNTAX      Integer32
  1539.        MAX-ACCESS  read-only
  1540.        STATUS      current
  1541.        DESCRIPTION
  1542.                "The size of the largest packet which can be
  1543.                sent/received on the interface, specified in octets.
  1544.                For interfaces that are used for transmitting network
  1545.                datagrams, this is the size of the largest network
  1546.                datagram that can be sent on the interface."
  1547.        ::= { ifEntry 4 }
  1548.  
  1549.    ifSpeed OBJECT-TYPE
  1550.        SYNTAX      Gauge32
  1551.        MAX-ACCESS  read-only
  1552.        STATUS      current
  1553.        DESCRIPTION
  1554.                "An estimate of the interface's current bandwidth in
  1555.                bits per second.  For interfaces which do not vary in
  1556.                bandwidth or for those where no accurate estimation
  1557.                can be made, this object should contain the nominal
  1558.                bandwidth.  If the bandwidth of the interface is
  1559.                greater than the maximum value reportable by this
  1560.                object then this object should report its maximum
  1561.                value (4,294,967,295) and ifHighSpeed must be used to
  1562.                report the interace's speed.  For a sub-layer which
  1563.                has no concept of bandwidth, this object should be
  1564.                zero."
  1565.        ::= { ifEntry 5 }
  1566.  
  1567.  
  1568.  
  1569.  
  1570. McCloghrie & Kastenholz                                        [Page 28]
  1571.  
  1572. RFC 1573               Interfaces Group Evolution           January 1994
  1573.  
  1574.  
  1575.    ifPhysAddress OBJECT-TYPE
  1576.        SYNTAX      PhysAddress
  1577.        MAX-ACCESS  read-only
  1578.        STATUS      current
  1579.        DESCRIPTION
  1580.                "The interface's address at its protocol sub-layer.
  1581.                The interface's media-specific MIB must define the bit
  1582.                and byte ordering and format of the value contained by
  1583.                this object.  For interfaces which do not have such an
  1584.                address (e.g., a serial line), this object should
  1585.                contain an octet string of zero length."
  1586.        ::= { ifEntry 6 }
  1587.  
  1588.    ifAdminStatus OBJECT-TYPE
  1589.        SYNTAX  INTEGER {
  1590.                    up(1),       -- ready to pass packets
  1591.                    down(2),
  1592.                    testing(3)   -- in some test mode
  1593.                }
  1594.        MAX-ACCESS  read-write
  1595.        STATUS      current
  1596.        DESCRIPTION
  1597.                "The desired state of the interface.  The testing(3)
  1598.                state indicates that no operational packets can be
  1599.                passed.  When a managed system initializes, all
  1600.                interfaces start with ifAdminStatus in the down(2)
  1601.                state.  As a result of either explicit management
  1602.                action or per configuration information retained by
  1603.                the managed system, ifAdminStatus is then changed to
  1604.                either the up(1) or testing(3) states (or remains in
  1605.                the down(2) state)."
  1606.        ::= { ifEntry 7 }
  1607.  
  1608.    ifOperStatus OBJECT-TYPE
  1609.        SYNTAX  INTEGER {
  1610.                    up(1),       -- ready to pass packets
  1611.                    down(2),
  1612.                    testing(3),  -- in some test mode
  1613.                    unknown(4),  -- status can not be determined
  1614.                                 -- for some reason.
  1615.                    dormant(5)
  1616.                }
  1617.        MAX-ACCESS  read-only
  1618.        STATUS      current
  1619.        DESCRIPTION
  1620.                "The current operational state of the interface.  The
  1621.                testing(3) state indicates that no operational packets
  1622.                can be passed.  If ifAdminStatus is down(2) then
  1623.  
  1624.  
  1625.  
  1626. McCloghrie & Kastenholz                                        [Page 29]
  1627.  
  1628. RFC 1573               Interfaces Group Evolution           January 1994
  1629.  
  1630.  
  1631.                ifOperStatus should be down(2).  If ifAdminStatus is
  1632.                changed to up(1) then ifOperStatus should change to
  1633.                up(1) if the interface is ready to transmit and
  1634.                receive network traffic; it should change to
  1635.                dormant(5) if the interface is waiting for external
  1636.                actions (such as a serial line waiting for an
  1637.                incomming connection); it should remain in the down(2)
  1638.                state if and only if there is a fault that prevents if
  1639.                from going to the up(1) state."
  1640.        ::= { ifEntry 8 }
  1641.  
  1642.    ifLastChange OBJECT-TYPE
  1643.        SYNTAX      TimeTicks
  1644.        MAX-ACCESS  read-only
  1645.        STATUS      current
  1646.        DESCRIPTION
  1647.                "The value of sysUpTime at the time the interface
  1648.                entered its current operational state.  If the current
  1649.                state was entered prior to the last re-initialization
  1650.                of the local network management subsystem, then this
  1651.                object contains a zero value."
  1652.        ::= { ifEntry 9 }
  1653.  
  1654.    ifInOctets OBJECT-TYPE
  1655.        SYNTAX      Counter32
  1656.        MAX-ACCESS  read-only
  1657.        STATUS      current
  1658.        DESCRIPTION
  1659.                "The total number of octets received on the interface,
  1660.                including framing characters."
  1661.        ::= { ifEntry 10 }
  1662.  
  1663.    ifInUcastPkts OBJECT-TYPE
  1664.        SYNTAX      Counter32
  1665.        MAX-ACCESS  read-only
  1666.        STATUS      current
  1667.        DESCRIPTION
  1668.                "The number of packets, delivered by this sub-layer to
  1669.                a higher (sub-)layer, which were not addressed to a
  1670.                multicast or broadcast address at this sub-layer."
  1671.        ::= { ifEntry 11 }
  1672.  
  1673.    ifInNUcastPkts OBJECT-TYPE
  1674.        SYNTAX  Counter32
  1675.        MAX-ACCESS  read-only
  1676.        STATUS      deprecated
  1677.        DESCRIPTION
  1678.                "The number of packets, delivered by this sub-layer to
  1679.  
  1680.  
  1681.  
  1682. McCloghrie & Kastenholz                                        [Page 30]
  1683.  
  1684. RFC 1573               Interfaces Group Evolution           January 1994
  1685.  
  1686.  
  1687.                a higher (sub-)layer, which were addressed to a
  1688.                multicast or broadcast address at this sub-layer.
  1689.                This object is deprecated in favour of
  1690.                ifInMulticastPkts and ifInBroadcastPkts."
  1691.        ::= { ifEntry 12 }
  1692.  
  1693.    ifInDiscards OBJECT-TYPE
  1694.        SYNTAX      Counter32
  1695.        MAX-ACCESS  read-only
  1696.        STATUS      current
  1697.        DESCRIPTION
  1698.                "The number of inbound packets which were chosen to be
  1699.                discarded even though no errors had been detected to
  1700.                prevent their being deliverable to a higher-layer
  1701.                protocol.  One possible reason for discarding such a
  1702.                packet could be to free up buffer space."
  1703.        ::= { ifEntry 13 }
  1704.  
  1705.    ifInErrors OBJECT-TYPE
  1706.        SYNTAX      Counter32
  1707.        MAX-ACCESS  read-only
  1708.        STATUS      current
  1709.        DESCRIPTION
  1710.                "For packet-oriented interfaces, the number of inbound
  1711.                packets that contained errors preventing them from
  1712.                being deliverable to a higher-layer protocol.  For
  1713.                character-oriented or fixed-length interfaces, the
  1714.                number of inbound transmission units that contained
  1715.                errors preventing them from being deliverable to a
  1716.                higher-layer protocol."
  1717.        ::= { ifEntry 14 }
  1718.  
  1719.    ifInUnknownProtos OBJECT-TYPE
  1720.        SYNTAX      Counter32
  1721.        MAX-ACCESS  read-only
  1722.        STATUS      current
  1723.        DESCRIPTION
  1724.                "For packet-oriented interfaces, the number of packets
  1725.                received via the interface which were discarded
  1726.                because of an unknown or unsupported protocol.  For
  1727.                character-oriented or fixed-length interfaces which
  1728.                support protocol multiplexing the number of
  1729.                transmission units received via the interface which
  1730.                were discarded because of an unknown or unsupported
  1731.                protocol.  For any interface which does not support
  1732.                protocol multiplexing, this counter will always be 0."
  1733.        ::= { ifEntry 15 }
  1734.  
  1735.  
  1736.  
  1737.  
  1738. McCloghrie & Kastenholz                                        [Page 31]
  1739.  
  1740. RFC 1573               Interfaces Group Evolution           January 1994
  1741.  
  1742.  
  1743.    ifOutOctets OBJECT-TYPE
  1744.        SYNTAX      Counter32
  1745.        MAX-ACCESS  read-only
  1746.        STATUS      current
  1747.        DESCRIPTION
  1748.                "The total number of octets transmitted out of the
  1749.                interface, including framing characters."
  1750.        ::= { ifEntry 16 }
  1751.  
  1752.    ifOutUcastPkts OBJECT-TYPE
  1753.        SYNTAX      Counter32
  1754.        MAX-ACCESS  read-only
  1755.        STATUS      current
  1756.        DESCRIPTION
  1757.  
  1758.                "The total number of packets that higher-level
  1759.                protocols requested be transmitted, and which were not
  1760.                addressed to a multicast or broadcast address at this
  1761.                sub-layer, including those that were discarded or not
  1762.                sent."
  1763.        ::= { ifEntry 17 }
  1764.  
  1765.    ifOutNUcastPkts OBJECT-TYPE
  1766.        SYNTAX      Counter32
  1767.        MAX-ACCESS  read-only
  1768.        STATUS      deprecated
  1769.        DESCRIPTION
  1770.                "The total number of packets that higher-level
  1771.                protocols requested be transmitted, and which were
  1772.                addressed to a multicast or broadcast address at this
  1773.                sub-layer, including those that were discarded or not
  1774.                sent.
  1775.  
  1776.                This object is deprecated in favour of
  1777.                ifOutMulticastPkts and ifOutBroadcastPkts."
  1778.        ::= { ifEntry 18 }
  1779.  
  1780.    ifOutDiscards OBJECT-TYPE
  1781.        SYNTAX      Counter32
  1782.        MAX-ACCESS  read-only
  1783.        STATUS      current
  1784.        DESCRIPTION
  1785.                "The number of outbound packets which were chosen to
  1786.                be discarded even though no errors had been detected
  1787.                to prevent their being transmitted.  One possible
  1788.                reason for discarding such a packet could be to free
  1789.                up buffer space."
  1790.        ::= { ifEntry 19 }
  1791.  
  1792.  
  1793.  
  1794. McCloghrie & Kastenholz                                        [Page 32]
  1795.  
  1796. RFC 1573               Interfaces Group Evolution           January 1994
  1797.  
  1798.  
  1799.    ifOutErrors OBJECT-TYPE
  1800.        SYNTAX      Counter32
  1801.        MAX-ACCESS  read-only
  1802.        STATUS      current
  1803.        DESCRIPTION
  1804.                "For packet-oriented interfaces, the number of
  1805.                outbound packets that could not be transmitted because
  1806.                of errors.  For character-oriented or fixed-length
  1807.                interfaces, the number of outbound transmission units
  1808.                that could not be transmitted because of errors."
  1809.        ::= { ifEntry 20 }
  1810.  
  1811.    ifOutQLen OBJECT-TYPE
  1812.        SYNTAX      Gauge32
  1813.        MAX-ACCESS  read-only
  1814.        STATUS      deprecated
  1815.        DESCRIPTION
  1816.                "The length of the output packet queue (in packets)."
  1817.        ::= { ifEntry 21 }
  1818.  
  1819.    ifSpecific OBJECT-TYPE
  1820.        SYNTAX      OBJECT IDENTIFIER
  1821.        MAX-ACCESS  read-only
  1822.        STATUS      deprecated
  1823.        DESCRIPTION
  1824.                "A reference to MIB definitions specific to the
  1825.                particular media being used to realize the interface.
  1826.                It is recommended that this value point to an instance
  1827.                of a MIB object in the media-specific MIB, i.e., that
  1828.                this object have the semantics associated with the
  1829.                InstancePointer textual convention defined in RFC
  1830.                1443.  In fact, it is recommended that the media-
  1831.                specific MIB specify what value ifSpecific should/can
  1832.                take for values of ifType.  If no MIB definitions
  1833.                specific to the particular media are available, the
  1834.                value should be set to the OBJECT IDENTIFIER { 0 0 }."
  1835.        ::= { ifEntry 22 }
  1836.  
  1837.  
  1838.    --
  1839.    --   Extension to the interface table
  1840.    --
  1841.    -- This table replaces the ifExtnsTable table.
  1842.    --
  1843.  
  1844.    ifXTable        OBJECT-TYPE
  1845.        SYNTAX      SEQUENCE OF IfXEntry
  1846.        MAX-ACCESS  not-accessible
  1847.  
  1848.  
  1849.  
  1850. McCloghrie & Kastenholz                                        [Page 33]
  1851.  
  1852. RFC 1573               Interfaces Group Evolution           January 1994
  1853.  
  1854.  
  1855.        STATUS      current
  1856.        DESCRIPTION
  1857.                "A list of interface entries.  The number of entries
  1858.                is given by the value of ifNumber.  This table
  1859.                contains additional objects for the interface table."
  1860.        ::= { ifMIBObjects 1 }
  1861.  
  1862.    ifXEntry        OBJECT-TYPE
  1863.        SYNTAX      IfXEntry
  1864.        MAX-ACCESS  not-accessible
  1865.        STATUS      current
  1866.        DESCRIPTION
  1867.                "An entry containing additional management information
  1868.                applicable to a particular interface."
  1869.        AUGMENTS    { ifEntry }
  1870.        ::= { ifXTable 1 }
  1871.  
  1872.    IfXEntry ::=
  1873.        SEQUENCE {
  1874.            ifName                  DisplayString,
  1875.            ifInMulticastPkts       Counter32,
  1876.            ifInBroadcastPkts       Counter32,
  1877.            ifOutMulticastPkts      Counter32,
  1878.            ifOutBroadcastPkts      Counter32,
  1879.            ifHCInOctets            Counter64,
  1880.            ifHCInUcastPkts         Counter64,
  1881.            ifHCInMulticastPkts     Counter64,
  1882.            ifHCInBroadcastPkts     Counter64,
  1883.            ifHCOutOctets           Counter64,
  1884.            ifHCOutUcastPkts        Counter64,
  1885.            ifHCOutMulticastPkts    Counter64,
  1886.            ifHCOutBroadcastPkts    Counter64,
  1887.            ifLinkUpDownTrapEnable  INTEGER,
  1888.            ifHighSpeed             Gauge32,
  1889.            ifPromiscuousMode       TruthValue,
  1890.            ifConnectorPresent      TruthValue
  1891.        }
  1892.  
  1893.  
  1894.    ifName OBJECT-TYPE
  1895.        SYNTAX      DisplayString
  1896.        MAX-ACCESS  read-only
  1897.        STATUS      current
  1898.        DESCRIPTION
  1899.                "The textual name of the interface.  The value of this
  1900.                object should be the name of the interface as assigned
  1901.                by the local device and should be suitable for use in
  1902.                commands entered at the device's `console'.  This
  1903.  
  1904.  
  1905.  
  1906. McCloghrie & Kastenholz                                        [Page 34]
  1907.  
  1908. RFC 1573               Interfaces Group Evolution           January 1994
  1909.  
  1910.  
  1911.                might be a text name, such as `le0' or a simple port
  1912.                number, such as `1', depending on the interface naming
  1913.                syntax of the device.  If several entries in the
  1914.                ifTable together represent a single interface as named
  1915.                by the device, then each will have the same value of
  1916.                ifName.  If there is no local name, or this object is
  1917.                otherwise not applicable, then this object contains a
  1918.                0-length string."
  1919.        ::= { ifXEntry 1 }
  1920.  
  1921.    ifInMulticastPkts OBJECT-TYPE
  1922.        SYNTAX      Counter32
  1923.        MAX-ACCESS  read-only
  1924.        STATUS      current
  1925.        DESCRIPTION
  1926.                "The number of packets, delivered by this sub-layer to
  1927.                a higher (sub-)layer, which were addressed to a
  1928.                multicast address at this sub-layer.  For a MAC layer
  1929.                protocol, this includes both Group and Functional
  1930.                addresses."
  1931.        ::= { ifXEntry 2 }
  1932.  
  1933.    ifInBroadcastPkts OBJECT-TYPE
  1934.        SYNTAX      Counter32
  1935.        MAX-ACCESS  read-only
  1936.        STATUS      current
  1937.        DESCRIPTION
  1938.                "The number of packets, delivered by this sub-layer to
  1939.                a higher (sub-)layer, which were addressed to a
  1940.                broadcast address at this sub-layer."
  1941.        ::= { ifXEntry 3 }
  1942.  
  1943.    ifOutMulticastPkts OBJECT-TYPE
  1944.        SYNTAX      Counter32
  1945.        MAX-ACCESS  read-only
  1946.        STATUS      current
  1947.        DESCRIPTION
  1948.                "The total number of packets that higher-level
  1949.                protocols requested be transmitted, and which were
  1950.                addressed to a multicast address at this sub-layer,
  1951.                including those that were discarded or not sent.  For
  1952.                a MAC layer protocol, this includes both Group and
  1953.                Functional addresses."
  1954.        ::= { ifXEntry 4 }
  1955.  
  1956.    ifOutBroadcastPkts OBJECT-TYPE
  1957.        SYNTAX      Counter32
  1958.        MAX-ACCESS  read-only
  1959.  
  1960.  
  1961.  
  1962. McCloghrie & Kastenholz                                        [Page 35]
  1963.  
  1964. RFC 1573               Interfaces Group Evolution           January 1994
  1965.  
  1966.  
  1967.        STATUS      current
  1968.        DESCRIPTION
  1969.                "The total number of packets that higher-level
  1970.                protocols requested be transmitted, and which were
  1971.                addressed to a broadcast address at this sub-layer,
  1972.                including those that were discarded or not sent."
  1973.        ::= { ifXEntry 5 }
  1974.  
  1975.    --
  1976.    -- High Capacity Counter objects.  These objects are all
  1977.  
  1978.    -- 64 bit versions of the "basic" ifTable counters.  These
  1979.    -- objects all have the same basic semantics as their 32-bit
  1980.    -- counterparts, however, their syntax has been extended
  1981.    -- to 64 bits.
  1982.    --
  1983.  
  1984.    ifHCInOctets OBJECT-TYPE
  1985.        SYNTAX      Counter64
  1986.        MAX-ACCESS  read-only
  1987.        STATUS      current
  1988.        DESCRIPTION
  1989.                "The total number of octets received on the interface,
  1990.                including framing characters.  This object is a 64-bit
  1991.                version of ifInOctets."
  1992.        ::= { ifXEntry 6 }
  1993.  
  1994.    ifHCInUcastPkts OBJECT-TYPE
  1995.        SYNTAX      Counter64
  1996.        MAX-ACCESS  read-only
  1997.        STATUS      current
  1998.        DESCRIPTION
  1999.                "The number of packets, delivered by this sub-layer to
  2000.                a higher (sub-)layer, which were not addressed to a
  2001.                multicast or broadcast address at this sub-layer.
  2002.                This object is a 64-bit version of ifInUcastPkts."
  2003.        ::= { ifXEntry 7 }
  2004.  
  2005.    ifHCInMulticastPkts OBJECT-TYPE
  2006.        SYNTAX      Counter64
  2007.        MAX-ACCESS  read-only
  2008.        STATUS      current
  2009.        DESCRIPTION
  2010.                "The number of packets, delivered by this sub-layer to
  2011.                a higher (sub-)layer, which were addressed to a
  2012.                multicast address at this sub-layer.  For a MAC layer
  2013.                protocol, this includes both Group and Functional
  2014.                addresses.  This object is a 64-bit version of
  2015.  
  2016.  
  2017.  
  2018. McCloghrie & Kastenholz                                        [Page 36]
  2019.  
  2020. RFC 1573               Interfaces Group Evolution           January 1994
  2021.  
  2022.  
  2023.                ifInMulticastPkts."
  2024.        ::= { ifXEntry 8 }
  2025.  
  2026.    ifHCInBroadcastPkts OBJECT-TYPE
  2027.        SYNTAX      Counter64
  2028.        MAX-ACCESS  read-only
  2029.        STATUS      current
  2030.        DESCRIPTION
  2031.                "The number of packets, delivered by this sub-layer to
  2032.                a higher (sub-)layer, which were addressed to a
  2033.                broadcast address at this sub-layer.  This object is a
  2034.                64-bit version of ifInBroadcastPkts."
  2035.        ::= { ifXEntry 9 }
  2036.  
  2037.    ifHCOutOctets OBJECT-TYPE
  2038.        SYNTAX      Counter64
  2039.        MAX-ACCESS  read-only
  2040.        STATUS      current
  2041.        DESCRIPTION
  2042.                "The total number of octets transmitted out of the
  2043.                interface, including framing characters.  This object
  2044.                is a 64-bit version of ifOutOctets."
  2045.        ::= { ifXEntry 10 }
  2046.  
  2047.    ifHCOutUcastPkts OBJECT-TYPE
  2048.        SYNTAX      Counter64
  2049.        MAX-ACCESS  read-only
  2050.        STATUS      current
  2051.        DESCRIPTION
  2052.                "The total number of packets that higher-level
  2053.                protocols requested be transmitted, and which were not
  2054.                addressed to a multicast or broadcast address at this
  2055.                sub-layer, including those that were discarded or not
  2056.                sent.  This object is a 64-bit version of
  2057.                ifOutUcastPkts."
  2058.        ::= { ifXEntry 11 }
  2059.  
  2060.    ifHCOutMulticastPkts OBJECT-TYPE
  2061.        SYNTAX      Counter64
  2062.        MAX-ACCESS  read-only
  2063.        STATUS      current
  2064.        DESCRIPTION
  2065.                "The total number of packets that higher-level
  2066.                protocols requested be transmitted, and which were
  2067.                addressed to a multicast address at this sub-layer,
  2068.                including those that were discarded or not sent.  For
  2069.                a MAC layer protocol, this includes both Group and
  2070.                Functional addresses.  This object is a 64-bit version
  2071.  
  2072.  
  2073.  
  2074. McCloghrie & Kastenholz                                        [Page 37]
  2075.  
  2076. RFC 1573               Interfaces Group Evolution           January 1994
  2077.  
  2078.  
  2079.                of ifOutMulticastPkts."
  2080.        ::= { ifXEntry 12 }
  2081.  
  2082.    ifHCOutBroadcastPkts OBJECT-TYPE
  2083.        SYNTAX      Counter64
  2084.        MAX-ACCESS  read-only
  2085.        STATUS      current
  2086.        DESCRIPTION
  2087.                "The total number of packets that higher-level
  2088.                protocols requested be transmitted, and which were
  2089.                addressed to a broadcast address at this sub-layer,
  2090.                including those that were discarded or not sent.  This
  2091.                object is a 64-bit version of ifOutBroadcastPkts."
  2092.        ::= { ifXEntry 13 }
  2093.  
  2094.    ifLinkUpDownTrapEnable  OBJECT-TYPE
  2095.        SYNTAX      INTEGER { enabled(1), disabled(2) }
  2096.        MAX-ACCESS  read-write
  2097.        STATUS      current
  2098.        DESCRIPTION
  2099.                "Indicates whether linkUp/linkDown traps should be
  2100.                generated for this interface.
  2101.  
  2102.                By default, this object should have the value
  2103.                enabled(1) for interfaces which do not operate on
  2104.                'top' of any other interface (as defined in the
  2105.                ifStackTable), and disabled(2) otherwise."
  2106.        ::= { ifXEntry 14 }
  2107.  
  2108.    ifHighSpeed OBJECT-TYPE
  2109.        SYNTAX      Gauge32
  2110.        MAX-ACCESS  read-only
  2111.        STATUS      current
  2112.        DESCRIPTION
  2113.                "An estimate of the interface's current bandwidth in
  2114.                units of 1,000,000 bits per second.  If this object
  2115.                reports a value of `n' then the speed of the interface
  2116.                is somewhere in the range of `n-500,000' to
  2117.                `n+499,999'.  For interfaces which do not vary in
  2118.                bandwidth or for those where no accurate estimation
  2119.                can be made, this object should contain the nominal
  2120.                bandwidth.  For a sub-layer which has no concept of
  2121.                bandwidth, this object should be zero."
  2122.        ::= { ifXEntry 15 }
  2123.  
  2124.    ifPromiscuousMode  OBJECT-TYPE
  2125.        SYNTAX      TruthValue
  2126.        MAX-ACCESS  read-write
  2127.  
  2128.  
  2129.  
  2130. McCloghrie & Kastenholz                                        [Page 38]
  2131.  
  2132. RFC 1573               Interfaces Group Evolution           January 1994
  2133.  
  2134.  
  2135.        STATUS      current
  2136.        DESCRIPTION
  2137.                "This object has a value of false(2) if this interface
  2138.                only accepts packets/frames that are addressed to this
  2139.                station.  This object has a value of true(1) when the
  2140.                station accepts all packets/frames transmitted on the
  2141.                media.  The value true(1) is only legal on certain
  2142.                types of media.  If legal, setting this object to a
  2143.                value of true(1) may require the interface to be reset
  2144.                before becoming effective.
  2145.  
  2146.                The value of ifPromiscuousMode does not affect the
  2147.                reception of broadcast and multicast packets/frames by
  2148.                the interface."
  2149.        ::= { ifXEntry 16 }
  2150.  
  2151.    ifConnectorPresent   OBJECT-TYPE
  2152.        SYNTAX      TruthValue
  2153.        MAX-ACCESS  read-only
  2154.        STATUS      current
  2155.        DESCRIPTION
  2156.                "This object has the value 'true(1)' if the interface
  2157.                sublayer has a physical connector and the value
  2158.                'false(2)' otherwise."
  2159.        ::= { ifXEntry 17 }
  2160.  
  2161.  
  2162.    --           The Interface Stack Group
  2163.    --
  2164.    -- Implementation of this group is mandatory for all systems
  2165.    --
  2166.  
  2167.    ifStackTable  OBJECT-TYPE
  2168.         SYNTAX        SEQUENCE OF IfStackEntry
  2169.         MAX-ACCESS    not-accessible
  2170.         STATUS        current
  2171.         DESCRIPTION
  2172.                "The table containing information on the relationships
  2173.                between the multiple sub-layers of network interfaces.
  2174.                In particular, it contains information on which sub-
  2175.                layers run 'on top of' which other sub-layers.  Each
  2176.                sub-layer corresponds to a conceptual row in the
  2177.                ifTable."
  2178.         ::= { ifMIBObjects 2 }
  2179.  
  2180.  
  2181.    ifStackEntry  OBJECT-TYPE
  2182.         SYNTAX        IfStackEntry
  2183.  
  2184.  
  2185.  
  2186. McCloghrie & Kastenholz                                        [Page 39]
  2187.  
  2188. RFC 1573               Interfaces Group Evolution           January 1994
  2189.  
  2190.  
  2191.         MAX-ACCESS    not-accessible
  2192.         STATUS        current
  2193.         DESCRIPTION
  2194.                "Information on a particular relationship between two
  2195.                sub-layers, specifying that one sub-layer runs on
  2196.                'top' of the other sub-layer.  Each sub-layer
  2197.                corresponds to a conceptual row in the ifTable."
  2198.         INDEX { ifStackHigherLayer, ifStackLowerLayer }
  2199.         ::= { ifStackTable 1 }
  2200.  
  2201.  
  2202.    IfStackEntry ::=
  2203.        SEQUENCE {
  2204.            ifStackHigherLayer  Integer32,
  2205.            ifStackLowerLayer   Integer32,
  2206.            ifStackStatus       RowStatus
  2207.         }
  2208.  
  2209.  
  2210.    ifStackHigherLayer  OBJECT-TYPE
  2211.         SYNTAX        Integer32
  2212.         MAX-ACCESS    not-accessible
  2213.         STATUS        current
  2214.         DESCRIPTION
  2215.                "The value of ifIndex corresponding to the higher
  2216.                sub-layer of the relationship, i.e., the sub-layer
  2217.                which runs on 'top' of the sub-layer identified by the
  2218.                corresponding instance of ifStackLowerLayer.  If there
  2219.                is no higher sub-layer (below the internetwork layer),
  2220.                then this object has the value 0."
  2221.         ::= { ifStackEntry 1 }
  2222.  
  2223.  
  2224.    ifStackLowerLayer  OBJECT-TYPE
  2225.         SYNTAX        Integer32
  2226.         MAX-ACCESS    not-accessible
  2227.         STATUS        current
  2228.         DESCRIPTION
  2229.                "The value of ifIndex corresponding to the lower sub-
  2230.                layer of the relationship, i.e., the sub-layer which
  2231.                runs 'below' the sub-layer identified by the
  2232.                corresponding instance of ifStackHigherLayer.  If
  2233.                there is no lower sub-layer, then this object has the
  2234.                value 0."
  2235.         ::= { ifStackEntry 2 }
  2236.  
  2237.  
  2238.    ifStackStatus  OBJECT-TYPE
  2239.  
  2240.  
  2241.  
  2242. McCloghrie & Kastenholz                                        [Page 40]
  2243.  
  2244. RFC 1573               Interfaces Group Evolution           January 1994
  2245.  
  2246.  
  2247.        SYNTAX         RowStatus
  2248.        MAX-ACCESS     read-write
  2249.        STATUS         current
  2250.        DESCRIPTION
  2251.                "The status of the relationship between two sub-
  2252.                layers.
  2253.  
  2254.                Changing the value of this object from 'active' to
  2255.                'notInService' or 'destroy' will likely have
  2256.                consequences up and down the interface stack.  Thus,
  2257.                write access to this object is likely to be
  2258.                inappropriate for some types of interfaces, and many
  2259.                implementations will choose not to support write-
  2260.                access for any type of interface."
  2261.        ::= { ifStackEntry 3 }
  2262.  
  2263.  
  2264.    --
  2265.    --    The Interface Test Table
  2266.    --
  2267.    -- This group of objects is optional.  However, a media-specific
  2268.    -- MIB may make implementation of this group mandatory.
  2269.    --
  2270.    -- This table replaces the ifExtnsTestTable
  2271.    --
  2272.  
  2273.    ifTestTable   OBJECT-TYPE
  2274.        SYNTAX      SEQUENCE OF IfTestEntry
  2275.        MAX-ACCESS  not-accessible
  2276.        STATUS      current
  2277.        DESCRIPTION
  2278.                "This table contains one entry per interface.  It
  2279.                defines objects which allow a network manager to
  2280.                instruct an agent to test an interface for various
  2281.                faults.  Tests for an interface are defined in the
  2282.                media-specific MIB for that interface.  After invoking
  2283.                a test, the object ifTestResult can be read to
  2284.                determine the outcome.  If an agent can not perform
  2285.                the test, ifTestResult is set to so indicate.  The
  2286.                object ifTestCode can be used to provide further
  2287.                test-specific or interface-specific (or even
  2288.                enterprise-specific) information concerning the
  2289.                outcome of the test.  Only one test can be in progress
  2290.                on each interface at any one time.  If one test is in
  2291.                progress when another test is invoked, the second test
  2292.                is rejected.  Some agents may reject a test when a
  2293.                prior test is active on another interface.
  2294.  
  2295.  
  2296.  
  2297.  
  2298. McCloghrie & Kastenholz                                        [Page 41]
  2299.  
  2300. RFC 1573               Interfaces Group Evolution           January 1994
  2301.  
  2302.  
  2303.                Before starting a test, a manager-station must first
  2304.                obtain 'ownership' of the entry in the ifTestTable for
  2305.                the interface to be tested.  This is accomplished with
  2306.                the ifTestId and ifTestStatus objects as follows:
  2307.  
  2308.             try_again:
  2309.                 get (ifTestId, ifTestStatus)
  2310.                 while (ifTestStatus != notInUse)
  2311.                     /*
  2312.                      * Loop while a test is running or some other
  2313.                      * manager is configuring a test.
  2314.                      */
  2315.                     short delay
  2316.                     get (ifTestId, ifTestStatus)
  2317.                 }
  2318.  
  2319.                 /*
  2320.                  * Is not being used right now -- let's compete
  2321.                  * to see who gets it.
  2322.                  */
  2323.                 lock_value = ifTestId
  2324.  
  2325.                 if ( set(ifTestId = lock_value, ifTestStatus = inUse,
  2326.                          ifTestOwner = 'my-IP-address') == FAILURE)
  2327.                     /*
  2328.                      * Another manager got the ifTestEntry -- go
  2329.                      * try again
  2330.                      */
  2331.                     goto try_again;
  2332.  
  2333.                 /*
  2334.                  * I have the lock
  2335.                  */
  2336.                 set up any test parameters.
  2337.  
  2338.                 /*
  2339.                  * This starts the test
  2340.                  */
  2341.                 set(ifTestType = test_to_run);
  2342.  
  2343.                 wait for test completion by polling ifTestResult
  2344.  
  2345.                 when test completes, agent sets ifTestResult
  2346.                      agent also sets ifTestStatus = 'notInUse'
  2347.  
  2348.                 retrieve any additional test results, and ifTestId
  2349.  
  2350.                 if (ifTestId == lock_value+1) results are valid
  2351.  
  2352.  
  2353.  
  2354. McCloghrie & Kastenholz                                        [Page 42]
  2355.  
  2356. RFC 1573               Interfaces Group Evolution           January 1994
  2357.  
  2358.  
  2359.               A manager station first retrieves the value of the
  2360.               appropriate ifTestId and ifTestStatus objects,
  2361.               periodically repeating the retrieval if necessary,
  2362.               until the value of ifTestStatus is 'notInUse'.  The
  2363.               manager station then tries to set the same ifTestId
  2364.               object to the value it just retrieved, the same
  2365.               ifTestStatus object to 'inUse', and the corresponding
  2366.               ifTestOwner object to a value indicating itself.  If
  2367.               the set operation succeeds then the manager has
  2368.               obtained ownership of the ifTestEntry, and the value of
  2369.               the ifTestId object is incremented by the agent (per
  2370.               the semantics of TestAndIncr).  Failure of the set
  2371.               operation indicates that some other manager has
  2372.               obtained ownership of the ifTestEntry.
  2373.  
  2374.               Once ownership is obtained, any test parameters can be
  2375.               setup, and then the test is initiated by setting
  2376.               ifTestType.  On completion of the test, the agent sets
  2377.               ifTestStatus to 'notInUse'.  Once this occurs, the
  2378.               manager can retrieve the results.  In the (rare) event
  2379.               that the invocation of tests by two network managers
  2380.               were to overlap, then there would be a possibility that
  2381.               the first test's results might be overwritten by the
  2382.               second test's results prior to the first results being
  2383.               read.  This unlikely circumstance can be detected by a
  2384.               network manager retrieving ifTestId at the same time as
  2385.               retrieving the test results, and ensuring that the
  2386.               results are for the desired request.
  2387.  
  2388.               If ifTestType is not set within an abnormally long
  2389.               period of time after ownership is obtained, the agent
  2390.               should time-out the manager, and reset the value of the
  2391.               ifTestStatus object back to 'notInUse'.  It is
  2392.               suggested that this time-out period be 5 minutes.
  2393.  
  2394.               In general, a management station must not retransmit a
  2395.               request to invoke a test for which it does not receive
  2396.               a response; instead, it properly inspects an agent's
  2397.               MIB to determine if the invocation was successful.
  2398.               Only if the invocation was unsuccessful, is the
  2399.               invocation request retransmitted.
  2400.  
  2401.               Some tests may require the interface to be taken off-
  2402.               line in order to execute them, or may even require the
  2403.               agent to reboot after completion of the test.  In these
  2404.               circumstances, communication with the management
  2405.               station invoking the test may be lost until after
  2406.               completion of the test.  An agent is not required to
  2407.  
  2408.  
  2409.  
  2410. McCloghrie & Kastenholz                                        [Page 43]
  2411.  
  2412. RFC 1573               Interfaces Group Evolution           January 1994
  2413.  
  2414.  
  2415.               support such tests.  However, if such tests are
  2416.               supported, then the agent should make every effort to
  2417.               transmit a response to the request which invoked the
  2418.               test prior to losing communication.  When the agent is
  2419.               restored to normal service, the results of the test are
  2420.               properly made available in the appropriate objects.
  2421.               Note that this requires that the ifIndex value assigned
  2422.               to an interface must be unchanged even if the test
  2423.               causes a reboot.  An agent must reject any test for
  2424.               which it cannot, perhaps due to resource constraints,
  2425.               make available at least the minimum amount of
  2426.               information after that test completes."
  2427.        ::= { ifMIBObjects 3 }
  2428.  
  2429.    ifTestEntry OBJECT-TYPE
  2430.        SYNTAX       IfTestEntry
  2431.        MAX-ACCESS   not-accessible
  2432.        STATUS       current
  2433.        DESCRIPTION
  2434.                "An entry containing objects for invoking tests on an
  2435.                interface."
  2436.        AUGMENTS  { ifEntry }
  2437.        ::= { ifTestTable 1 }
  2438.  
  2439.    IfTestEntry ::=
  2440.        SEQUENCE {
  2441.            ifTestId           TestAndIncr,
  2442.            ifTestStatus       INTEGER,
  2443.            ifTestType         AutonomousType,
  2444.            ifTestResult       INTEGER,
  2445.            ifTestCode         OBJECT IDENTIFIER,
  2446.            ifTestOwner        OwnerString
  2447.        }
  2448.  
  2449.    ifTestId         OBJECT-TYPE
  2450.        SYNTAX       TestAndIncr
  2451.        MAX-ACCESS   read-write
  2452.        STATUS       current
  2453.        DESCRIPTION
  2454.                "This object identifies the current invocation of the
  2455.                interface's test."
  2456.        ::= { ifTestEntry 1 }
  2457.  
  2458.    ifTestStatus     OBJECT-TYPE
  2459.        SYNTAX       INTEGER { notInUse(1), inUse(2) }
  2460.        MAX-ACCESS   read-write
  2461.        STATUS       current
  2462.        DESCRIPTION
  2463.  
  2464.  
  2465.  
  2466. McCloghrie & Kastenholz                                        [Page 44]
  2467.  
  2468. RFC 1573               Interfaces Group Evolution           January 1994
  2469.  
  2470.  
  2471.                "This object indicates whether or not some manager
  2472.                currently has the necessary 'ownership' required to
  2473.                invoke a test on this interface.  A write to this
  2474.                object is only successful when it changes its value
  2475.                from 'notInUse(1)' to 'inUse(2)'.  After completion of
  2476.                a test, the agent resets the value back to
  2477.                'notInUse(1)'."
  2478.        ::= { ifTestEntry 2 }
  2479.  
  2480.    ifTestType       OBJECT-TYPE
  2481.        SYNTAX       AutonomousType
  2482.        MAX-ACCESS   read-write
  2483.        STATUS       current
  2484.        DESCRIPTION
  2485.                "A control variable used to start and stop operator-
  2486.                initiated interface tests.  Most OBJECT IDENTIFIER
  2487.                values assigned to tests are defined elsewhere, in
  2488.                association with specific types of interface.
  2489.                However, this document assigns a value for a full-
  2490.                duplex loopback test, and defines the special meanings
  2491.                of the subject identifier:
  2492.  
  2493.                    noTest  OBJECT IDENTIFIER ::= { 0 0 }
  2494.  
  2495.                When the value noTest is written to this object, no
  2496.                action is taken unless a test is in progress, in which
  2497.                case the test is aborted.  Writing any other value to
  2498.                this object is only valid when no test is currently in
  2499.                progress, in which case the indicated test is
  2500.                initiated.
  2501.  
  2502.                When read, this object always returns the most recent
  2503.                value that ifTestType was set to.  If it has not been
  2504.                set since the last initialization of the network
  2505.                management subsystem on the agent, a value of noTest
  2506.                is returned."
  2507.        ::= { ifTestEntry 3 }
  2508.  
  2509.    ifTestResult  OBJECT-TYPE
  2510.        SYNTAX       INTEGER {
  2511.                         none(1),          -- no test yet requested
  2512.                         success(2),
  2513.                         inProgress(3),
  2514.                         notSupported(4),
  2515.                         unAbleToRun(5),   -- due to state of system
  2516.                         aborted(6),
  2517.                         failed(7)
  2518.                     }
  2519.  
  2520.  
  2521.  
  2522. McCloghrie & Kastenholz                                        [Page 45]
  2523.  
  2524. RFC 1573               Interfaces Group Evolution           January 1994
  2525.  
  2526.  
  2527.        MAX-ACCESS   read-only
  2528.        STATUS       current
  2529.        DESCRIPTION
  2530.                "This object contains the result of the most recently
  2531.                requested test, or the value none(1) if no tests have
  2532.                been requested since the last reset.  Note that this
  2533.                facility provides no provision for saving the results
  2534.                of one test when starting another, as could be
  2535.                required if used by multiple managers concurrently."
  2536.        ::= { ifTestEntry 4 }
  2537.  
  2538.    ifTestCode  OBJECT-TYPE
  2539.        SYNTAX       OBJECT IDENTIFIER
  2540.        MAX-ACCESS   read-only
  2541.        STATUS       current
  2542.        DESCRIPTION
  2543.                "This object contains a code which contains more
  2544.                specific information on the test result, for example
  2545.                an error-code after a failed test.  Error codes and
  2546.                other values this object may take are specific to the
  2547.                type of interface and/or test.  The value may have the
  2548.                semantics of either the AutonomousType or
  2549.                InstancePointer textual conventions as defined in RFC
  2550.                1443.  The identifier:
  2551.  
  2552.                    testCodeUnknown  OBJECT IDENTIFIER ::= { 0 0 }
  2553.  
  2554.                is defined for use if no additional result code is
  2555.                available."
  2556.        ::= { ifTestEntry 5 }
  2557.  
  2558.    ifTestOwner      OBJECT-TYPE
  2559.        SYNTAX       OwnerString
  2560.        MAX-ACCESS   read-write
  2561.        STATUS       current
  2562.        DESCRIPTION
  2563.                "The entity which currently has the 'ownership'
  2564.                required to invoke a test on this interface."
  2565.        ::= { ifTestEntry 6 }
  2566.  
  2567.  
  2568.    --   Generic Receive Address Table
  2569.    --
  2570.    -- This group of objects is mandatory for all types of
  2571.    -- interfaces which can receive packets/frames addressed to
  2572.    -- more than one address.
  2573.    --
  2574.    -- This table replaces the ifExtnsRcvAddr table.  The main
  2575.  
  2576.  
  2577.  
  2578. McCloghrie & Kastenholz                                        [Page 46]
  2579.  
  2580. RFC 1573               Interfaces Group Evolution           January 1994
  2581.  
  2582.  
  2583.    -- difference is that this table makes use of the RowStatus
  2584.    -- textual convention, while ifExtnsRcvAddr did not.
  2585.  
  2586.    ifRcvAddressTable  OBJECT-TYPE
  2587.        SYNTAX      SEQUENCE OF IfRcvAddressEntry
  2588.        MAX-ACCESS  not-accessible
  2589.        STATUS      current
  2590.        DESCRIPTION
  2591.                "This table contains an entry for each address
  2592.                (broadcast, multicast, or uni-cast) for which the
  2593.                system will receive packets/frames on a particular
  2594.                interface, except as follows:
  2595.  
  2596.                - for an interface operating in promiscuous mode,
  2597.                entries are only required for those addresses for
  2598.                which the system would receive frames were it not
  2599.                operating in promiscuous mode.
  2600.  
  2601.                - for 802.5 functional addresses, only one entry is
  2602.                required, for the address which has the functional
  2603.                address bit ANDed with the bit mask of all functional
  2604.                addresses for which the interface will accept frames."
  2605.        ::= { ifMIBObjects 4 }
  2606.  
  2607.    ifRcvAddressEntry  OBJECT-TYPE
  2608.        SYNTAX      IfRcvAddressEntry
  2609.        MAX-ACCESS  not-accessible
  2610.        STATUS      current
  2611.        DESCRIPTION
  2612.                "A list of objects identifying an address for which
  2613.                the system will accept packets/frames on the
  2614.                particular interface identified by the index value
  2615.                ifIndex."
  2616.        INDEX  { ifIndex, ifRcvAddressAddress }
  2617.        ::= { ifRcvAddressTable 1 }
  2618.  
  2619.    IfRcvAddressEntry ::=
  2620.        SEQUENCE {
  2621.            ifRcvAddressAddress   PhysAddress,
  2622.            ifRcvAddressStatus    RowStatus,
  2623.            ifRcvAddressType      INTEGER
  2624.        }
  2625.  
  2626.    ifRcvAddressAddress OBJECT-TYPE
  2627.        SYNTAX      PhysAddress
  2628.        MAX-ACCESS  read-create
  2629.        STATUS      current
  2630.        DESCRIPTION
  2631.  
  2632.  
  2633.  
  2634. McCloghrie & Kastenholz                                        [Page 47]
  2635.  
  2636. RFC 1573               Interfaces Group Evolution           January 1994
  2637.  
  2638.  
  2639.                "An address for which the system will accept
  2640.                packets/frames on this entry's interface."
  2641.        ::= { ifRcvAddressEntry 1 }
  2642.  
  2643.    ifRcvAddressStatus OBJECT-TYPE
  2644.        SYNTAX      RowStatus
  2645.        MAX-ACCESS  read-write
  2646.        STATUS      current
  2647.        DESCRIPTION
  2648.                "This object is used to create and delete rows in the
  2649.                ifRcvAddressTable."
  2650.  
  2651.        ::= { ifRcvAddressEntry 2 }
  2652.  
  2653.    ifRcvAddressType OBJECT-TYPE
  2654.        SYNTAX      INTEGER {
  2655.                        other(1),
  2656.                        volatile(2),
  2657.                        nonVolatile(3)
  2658.                    }
  2659.  
  2660.        MAX-ACCESS  read-create
  2661.        STATUS      current
  2662.        DESCRIPTION
  2663.                "This object has the value nonVolatile(3) for those
  2664.                entries in the table which are valid and will not be
  2665.                deleted by the next restart of the managed system.
  2666.                Entries having the value volatile(2) are valid and
  2667.                exist, but have not been saved, so that will not exist
  2668.                after the next restart of the managed system.  Entries
  2669.                having the value other(1) are valid and exist but are
  2670.                not classified as to whether they will continue to
  2671.                exist after the next restart."
  2672.  
  2673.        DEFVAL  { volatile }
  2674.  
  2675.        ::= { ifRcvAddressEntry 3 }
  2676.  
  2677.  
  2678.    -- definition of interface-related traps.
  2679.  
  2680.    linkDown NOTIFICATION-TYPE
  2681.        OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
  2682.        STATUS  current
  2683.        DESCRIPTION
  2684.                "A linkDown trap signifies that the SNMPv2 entity,
  2685.                acting in an agent role, has detected that the
  2686.                ifOperStatus object for one of its communication links
  2687.  
  2688.  
  2689.  
  2690. McCloghrie & Kastenholz                                        [Page 48]
  2691.  
  2692. RFC 1573               Interfaces Group Evolution           January 1994
  2693.  
  2694.  
  2695.                is about to transition into the down state."
  2696.        ::= { snmpTraps 3 }
  2697.  
  2698.    linkUp NOTIFICATION-TYPE
  2699.        OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
  2700.        STATUS  current
  2701.        DESCRIPTION
  2702.                "A linkUp trap signifies that the SNMPv2 entity,
  2703.                acting in an agent role, has detected that the
  2704.                ifOperStatus object for one of its communication links
  2705.                has transitioned out of the down state."
  2706.        ::= { snmpTraps 4 }
  2707.  
  2708.  
  2709.    -- conformance information
  2710.  
  2711.    ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 }
  2712.  
  2713.    ifGroups      OBJECT IDENTIFIER ::= { ifConformance 1 }
  2714.    ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 }
  2715.  
  2716.  
  2717.    -- compliance statements
  2718.  
  2719.    ifCompliance MODULE-COMPLIANCE
  2720.        STATUS  current
  2721.        DESCRIPTION
  2722.                "The compliance statement for SNMPv2 entities which
  2723.                have network interfaces."
  2724.  
  2725.        MODULE  -- this module
  2726.            MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup }
  2727.  
  2728.            GROUP       ifFixedLengthGroup
  2729.            DESCRIPTION
  2730.                "This group is mandatory for all network interfaces
  2731.                which are character-oriented or transmit data in
  2732.                fixed-length transmission units."
  2733.  
  2734.            GROUP       ifHCFixedLengthGroup
  2735.            DESCRIPTION
  2736.                "This group is mandatory only for those network
  2737.                interfaces which are character-oriented or transmit
  2738.                data in fixed-length transmission units, and for which
  2739.                the value of the corresponding instance of ifSpeed is
  2740.                greater than 20,000,000 bits/second."
  2741.  
  2742.            GROUP       ifPacketGroup
  2743.  
  2744.  
  2745.  
  2746. McCloghrie & Kastenholz                                        [Page 49]
  2747.  
  2748. RFC 1573               Interfaces Group Evolution           January 1994
  2749.  
  2750.  
  2751.            DESCRIPTION
  2752.                "This group is mandatory for all network interfaces
  2753.                which are packet-oriented."
  2754.  
  2755.            GROUP       ifHCPacketGroup
  2756.            DESCRIPTION
  2757.                "This group is mandatory only for those network
  2758.                interfaces which are packet-oriented and for which the
  2759.                value of the corresponding instance of ifSpeed is
  2760.                greater than 650,000,000 bits/second."
  2761.            GROUP       ifTestGroup
  2762.            DESCRIPTION
  2763.                "This group is optional.  Media-specific MIBs which
  2764.                require interface tests are strongly encouraged to use
  2765.                this group for invoking tests and reporting results.
  2766.                A medium specific MIB which has mandatory tests may
  2767.                make implementation of this group mandatory."
  2768.  
  2769.            GROUP       ifRcvAddressGroup
  2770.            DESCRIPTION
  2771.                "The applicability of this group MUST be defined by
  2772.                the media-specific MIBs.  Media-specific MIBs must
  2773.                define the exact meaning, use, and semantics of the
  2774.                addresses in this group."
  2775.  
  2776.            OBJECT      ifLinkUpDownTrapEnable
  2777.            MIN-ACCESS  read-only
  2778.            DESCRIPTION
  2779.                "Write access is not required."
  2780.  
  2781.            OBJECT      ifPromiscuousMode
  2782.            MIN-ACCESS  read-only
  2783.            DESCRIPTION
  2784.                "Write access is not required."
  2785.  
  2786.            OBJECT      ifStackStatus
  2787.            SYNTAX      INTEGER { active(1) } -- subset of RowStatus
  2788.            MIN-ACCESS  read-only
  2789.            DESCRIPTION
  2790.                "Write access is not required, and only one of the six
  2791.                enumerated values for the RowStatus textual convention
  2792.                need be supported, specifically: active(1)."
  2793.  
  2794.            OBJECT       ifAdminStatus
  2795.            SYNTAX       INTEGER { up(1), down(2) }
  2796.            MIN-ACCESS   read-only
  2797.            DESCRIPTION
  2798.                "Write access is not required, nor is support for the
  2799.  
  2800.  
  2801.  
  2802. McCloghrie & Kastenholz                                        [Page 50]
  2803.  
  2804. RFC 1573               Interfaces Group Evolution           January 1994
  2805.  
  2806.  
  2807.                value testing(3)."
  2808.        ::= { ifCompliances 1 }
  2809.  
  2810.  
  2811.    -- units of conformance
  2812.  
  2813.    ifGeneralGroup    OBJECT-GROUP
  2814.        OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress,
  2815.                  ifAdminStatus, ifOperStatus, ifLastChange,
  2816.                  ifLinkUpDownTrapEnable, ifConnectorPresent,
  2817.                  ifHighSpeed, ifName }
  2818.        STATUS  current
  2819.        DESCRIPTION
  2820.                "A collection of objects providing information
  2821.                applicable to all network interfaces."
  2822.        ::= { ifGroups 1 }
  2823.  
  2824.    -- the following five groups are mutually exclusive; at most
  2825.    -- one of these groups is implemented for any interface
  2826.  
  2827.    ifFixedLengthGroup    OBJECT-GROUP
  2828.        OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos,
  2829.                  ifInErrors, ifOutErrors }
  2830.        STATUS  current
  2831.        DESCRIPTION
  2832.                "A collection of objects providing information
  2833.                specific to non-high speed, character-oriented or
  2834.                fixed-length-transmission network interfaces.  (Non-
  2835.                high speed interfaces transmit and receive at speeds
  2836.                less than or equal to 20,000,000 bits/second.)"
  2837.        ::= { ifGroups 2 }
  2838.  
  2839.    ifHCFixedLengthGroup    OBJECT-GROUP
  2840.        OBJECTS { ifHCInOctets, ifHCOutOctets,
  2841.                  ifInOctets, ifOutOctets, ifInUnknownProtos,
  2842.                  ifInErrors, ifOutErrors }
  2843.        STATUS  current
  2844.        DESCRIPTION
  2845.                "A collection of objects providing information
  2846.                specific to high speed (greater than 20,000,000
  2847.                bits/second) character-oriented or fixed-length-
  2848.                transmission network interfaces."
  2849.        ::= { ifGroups 3 }
  2850.  
  2851.    ifPacketGroup    OBJECT-GROUP
  2852.        OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos,
  2853.                  ifInErrors, ifOutErrors,
  2854.                  ifMtu, ifInUcastPkts, ifInMulticastPkts,
  2855.  
  2856.  
  2857.  
  2858. McCloghrie & Kastenholz                                        [Page 51]
  2859.  
  2860. RFC 1573               Interfaces Group Evolution           January 1994
  2861.  
  2862.  
  2863.                  ifInBroadcastPkts, ifInDiscards,
  2864.                  ifOutUcastPkts, ifOutMulticastPkts,
  2865.                  ifOutBroadcastPkts, ifOutDiscards,
  2866.                  ifPromiscuousMode }
  2867.        STATUS  current
  2868.        DESCRIPTION
  2869.                "A collection of objects providing information
  2870.                specific to non-high speed, packet-oriented network
  2871.                interfaces.  (Non-high speed interfaces transmit and
  2872.                receive at speeds less than or equal to 20,000,000
  2873.                bits/second.)"
  2874.        ::= { ifGroups 4 }
  2875.  
  2876.    ifHCPacketGroup    OBJECT-GROUP
  2877.        OBJECTS { ifHCInOctets, ifHCOutOctets,
  2878.                  ifInOctets, ifOutOctets, ifInUnknownProtos,
  2879.                  ifInErrors, ifOutErrors,
  2880.                  ifMtu, ifInUcastPkts, ifInMulticastPkts,
  2881.                  ifInBroadcastPkts, ifInDiscards,
  2882.                  ifOutUcastPkts, ifOutMulticastPkts,
  2883.                  ifOutBroadcastPkts, ifOutDiscards,
  2884.                  ifPromiscuousMode }
  2885.        STATUS  current
  2886.        DESCRIPTION
  2887.                "A collection of objects providing information
  2888.                specific to high speed (greater than 20,000,000
  2889.                bits/second but less than or equal to 650,000,000
  2890.                bits/second) packet-oriented network interfaces."
  2891.        ::= { ifGroups 5 }
  2892.  
  2893.    ifVHCPacketGroup    OBJECT-GROUP
  2894.        OBJECTS { ifHCInUcastPkts, ifHCInMulticastPkts,
  2895.                  ifHCInBroadcastPkts, ifHCOutUcastPkts,
  2896.                  ifHCOutMulticastPkts, ifHCOutBroadcastPkts,
  2897.                  ifHCInOctets, ifHCOutOctets,
  2898.                  ifInOctets, ifOutOctets, ifInUnknownProtos,
  2899.                  ifInErrors, ifOutErrors,
  2900.                  ifMtu, ifInUcastPkts, ifInMulticastPkts,
  2901.                  ifInBroadcastPkts, ifInDiscards,
  2902.                  ifOutUcastPkts, ifOutMulticastPkts,
  2903.                  ifOutBroadcastPkts, ifOutDiscards,
  2904.                  ifPromiscuousMode }
  2905.        STATUS  current
  2906.        DESCRIPTION
  2907.                "A collection of objects providing information
  2908.                specific to higher speed (greater than 650,000,000
  2909.                bits/second) packet-oriented network interfaces."
  2910.        ::= { ifGroups 6 }
  2911.  
  2912.  
  2913.  
  2914. McCloghrie & Kastenholz                                        [Page 52]
  2915.  
  2916. RFC 1573               Interfaces Group Evolution           January 1994
  2917.  
  2918.  
  2919.    ifRcvAddressGroup    OBJECT-GROUP
  2920.        OBJECTS { ifRcvAddressStatus, ifRcvAddressType }
  2921.        STATUS  current
  2922.        DESCRIPTION
  2923.                "A collection of objects providing information on the
  2924.                multiple addresses which an interface receives."
  2925.        ::= { ifGroups 7 }
  2926.  
  2927.    ifTestGroup    OBJECT-GROUP
  2928.        OBJECTS { ifTestId, ifTestStatus, ifTestType,
  2929.                  ifTestResult, ifTestCode, ifTestOwner }
  2930.        STATUS  current
  2931.        DESCRIPTION
  2932.                "A collection of objects providing the ability to
  2933.                invoke tests on an interface."
  2934.        ::= { ifGroups 8 }
  2935.  
  2936.    ifStackGroup    OBJECT-GROUP
  2937.        OBJECTS { ifStackStatus }
  2938.        STATUS  current
  2939.        DESCRIPTION
  2940.                "A collection of objects providing information on the
  2941.                layering of MIB-II interfaces."
  2942.        ::= { ifGroups 9 }
  2943.  
  2944.    END
  2945.  
  2946. 7.  Acknowledgements
  2947.  
  2948.    This memo has been produced by the IETF's Interfaces MIB Working
  2949.    Group.
  2950.  
  2951.    The initial proposal to the working group was the result of
  2952.    conversations and discussions with many people, including at least
  2953.    the following: Fred Baker, Ted Brunner, Chuck Davin, Jeremy Greene,
  2954.    Marshall Rose, Kaj Tesink, and Dean Throop.
  2955.  
  2956. 8.  References
  2957.  
  2958.    [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
  2959.        of Management Information for version 2 of the Simple Network
  2960.        Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
  2961.        Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
  2962.        University, April 1993.
  2963.  
  2964.    [2] Galvin, J., and K. McCloghrie, "Administrative Model for version
  2965.        2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
  2966.        Trusted Information Systems, Hughes LAN Systems, April 1993.
  2967.  
  2968.  
  2969.  
  2970. McCloghrie & Kastenholz                                        [Page 53]
  2971.  
  2972. RFC 1573               Interfaces Group Evolution           January 1994
  2973.  
  2974.  
  2975.    [3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
  2976.        Operations for version 2 of the Simple Network Management
  2977.        Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
  2978.        Systems, Dover Beach Consulting, Inc., Carnegie Mellon
  2979.        University, April 1993.
  2980.  
  2981.    [4] McCloghrie, K., and M. Rose, "Management Information Base for
  2982.        Network Management of TCP/IP-based internets - MIB-II", STD 17,
  2983.        RFC 1213, Hughes LAN Systems, Performance Systems International,
  2984.        March 1991.
  2985.  
  2986.    [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
  2987.        Network Management Protocol", RFC 1157, SNMP Research,
  2988.        Performance Systems International, Performance Systems
  2989.        International, MIT Laboratory for Computer Science, May 1990.
  2990.  
  2991.    [6] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
  2992.        Sciences Institute, September 1981.
  2993.  
  2994.    [7] McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC
  2995.        1229, Hughes LAN Systems, May 1991.
  2996.  
  2997.    [8] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
  2998.        Conventions for version 2 of the Simple Network Management
  2999.        Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN
  3000.        Systems, Dover Beach Consulting, Inc., Carnegie Mellon
  3001.        University, April 1993.
  3002.  
  3003.  
  3004.  
  3005.  
  3006.  
  3007.  
  3008.  
  3009.  
  3010.  
  3011.  
  3012.  
  3013.  
  3014.  
  3015.  
  3016.  
  3017.  
  3018.  
  3019.  
  3020.  
  3021.  
  3022.  
  3023.  
  3024.  
  3025.  
  3026. McCloghrie & Kastenholz                                        [Page 54]
  3027.  
  3028. RFC 1573               Interfaces Group Evolution           January 1994
  3029.  
  3030.  
  3031. 9.  Security Considerations
  3032.  
  3033.    Security issues are not discussed in this memo.
  3034.  
  3035. 10.  Authors' Addresses
  3036.  
  3037.    Keith McCloghrie
  3038.    Hughes LAN Systems
  3039.    1225 Charleston Rd,
  3040.    Mountain View, Ca 94043
  3041.  
  3042.    Phone: 415-966-7934
  3043.    EMail: kzm@hls.com
  3044.  
  3045.  
  3046.    Frank Kastenholz
  3047.    FTP Software
  3048.    2 High Street
  3049.    North Andover, Mass. USA 01845
  3050.  
  3051.    Phone: (508)685-4000
  3052.    EMail: kasten@ftp.com
  3053.  
  3054.  
  3055.  
  3056.  
  3057.  
  3058.  
  3059.  
  3060.  
  3061.  
  3062.  
  3063.  
  3064.  
  3065.  
  3066.  
  3067.  
  3068.  
  3069.  
  3070.  
  3071.  
  3072.  
  3073.  
  3074.  
  3075.  
  3076.  
  3077.  
  3078.  
  3079.  
  3080.  
  3081.  
  3082. McCloghrie & Kastenholz                                        [Page 55]
  3083.  
  3084.